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GAME PLAN 



LETTER FROM THE EDITOR 



Surveying the Publishing Landscape 



Any great partnership can 
be characterized by the 
quality of its sum being 
greater than its parts. 
Developers and publish- 
ers have long benefited from a form of 
symbiosis in their respective courses of 
evolution, but the escalation of the busi- 
ness in the past few years has brought 
developers both uncertainty and oppor- 
tunity, confusion and validation, and 
more than a few heartbreaks to offset 
its millionaires. Natural selection bears 
its fangs. 

In such a hospitable environment of 
contradictions, generalizations enjoy 
abundance: "Publishers only do sequels 
and licenses!" "It's impossible for third- 
party developers these days!" "The 
French are taking over!" "They're all 
just out to screw us!" 

The business is changing, but is it 
really as bad as all that? To find out, we 
set out to analyze the Top 20 game soft- 
ware publishers in the world. We dug 
up release lists and analyzed the output 
of sequels and licenses. We figured out 
the percentage of each publisher's 
reliance on outside development. For 
those who have ever lamented working 
with a good producer at a bad publish- 
er, or a bad producer at a good publish- 
er, we surveyed willing developers on 
their relationship experiences with their 
partners, also incorporating feedback 
regarding milestone payment efficiency 
and level of creative involvement. 

When I first discussed the idea of put- 
ting this report together with its author, 
Tristan Donovan, we debated the right 
number of publishers to include: Ten? 
Fifteen? Twenty-five? We realized there 
are a lot more small publishers still very 
much afloat than we had thought, many 
of whom aren't represented in our Top 
20 but are still eking out a perfectly 
respectable living through niche markets 
or geographical specialization. 

Meanwhile, one of our 20 has a stick- 
er shock-inducing "for sale" sign plant- 
ed out front (warranty not included), 
one erstwhile stalwart gave up the ghost 



during the course of our research, and a 
few others teeter on the brink with ever 
more arresting precariousness, causing 
us to wonder whether our Top 20 might 
yet end up smaller in number somewhere 
between our printer and your mailbox. 

That a 20-year-old French company 
with a rainbow-colored armadillo for a 
mascot would suddenly and brazenly 
affix the Scarlet Atari to its chest added 
some absurdist flair, but we'll all get 
used to it in time. The SEC opened 
investigations into four of the Top 20 
for the extremely impolite-sounding 
practice of "channel stuffing," investiga- 
tions which at press time looked to be 
ongoing for the conceivable future. 

Though the companies on our list 
represent more than $11 billion in 
worldwide game software sales, the 
business is still fraught with uncertainty. 
As long as uncertainty propagates to the 
analyst and investor level for game pub- 
lishers, their long-term growth strategies 
will battle quarterly forecasts head-on, 
leaving developers on the creative and 
financial fence. Whether you love your 
publisher or hate them, whether you 
have a plum deal or a rotten apple, the 
future of the commercial game industry 
is in their hands. 

Shop talk. Also this month, longtime 
Artist's View columnist Hayden Duvall 
drops the bomb that he will shortly 
hang up his writing hat: October will be 
his last column. While I look forward to 
revealing his eager successor in Novem- 
ber, Hayden's lively personality, replete 
with irreverent humor that never fails to 
smart with the sting of truth, will be 
irreplaceable and greatly missed. Now 
that Hayden has hopped the pond to 
Garland, Texas, will this give him more 
time to help finish that game 3D Realms 
is working on? 

Jennifer Olsen 
Editor-in-Chief 
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^INDUSTRY WATCH 



KEEPING AN EYE ON THE GAME BIZ | jamil moledina 



Judge blocks videogame violence law. U.S. 
District Judge Robert Lasnik ordered an 
injunction blocking the enforcement of 
Washington state's recently passed legis- 
lation restricting the sale of violent 
games to minors. The bill would have 
fined retailers $500 for selling a game 
depicting violence against law enforce- 
ment officers to anyone under the age of 
17. The Interactive Digital Software 
Association (IDSA) and the Internation- 
al Game Developers Association (IGDA) 
joined the lawsuit arguing that video- 
games are protected by the First Amend- 
ment. In a nine-page opinion, Judge 
Lasnik wrote that the plaintiffs had 
"raised serious questions regarding the 
constitutionality of [the law]." 

Activision sues Viacom, phaser on stun. 

Activision filed a breach of contract law- 
suit against Viacom alleging that it 
allowed the Star Trek franchise to stag- 





Star Trek licensee Activision, publisher of Star 
Trek Elite Force II, is suing licensor Viacom 
over the franchise's poor performance. 

nate. Activision said it was terminating 
its agreement to license the Star Trek 
property because Viacom, through its 
subsidiary Paramount, released only one 
Star Trek film in the five years since the 
agreement was signed, has no plans for 
more films, let two Star Trek shows go 
off the air, and did not coordinate the 
development and marketing of Star 
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DEVELOPMENT SOFTWARE; 
AND OTHER STUFF 



HARDWARE 



NewTek gives more textures. NewTek 
recently released Texture Collection, 
Third Edition, a set of 50 high-resolu- 
tion JPEG images. These include tex- 
tures such as wood, metal, sky, nature, 
and stone. All are available as a free 
download, www.newtek.com 

Turbo Squid improves 3DS Max plug-in. 

Turbo Squid released an updated ver- 
sion of its 3DS Max plug-in that 
enables complex rendering in large 
(more than 50 million polygons) 
scenes. The FinalRender Stage-1 plug- 
in supports distributed rendering and 
includes effects such as 3D motion 
blurring, light dispersion, and sub-sur- 
face scattering. The plug-in is avail- 
able now for $795. 
www.turbosquid.com 

Khronos Group extends cross-platform pro- 
gramming. The Khronos Group launched 



OpenML 1.0 SDK, a cross-platform 
software development kit for manipulat- 
ing digital media, that runs on both 
Windows and Linux. Khronos also rati- 
fied the OpenGL ES 1.0 standard, 
which enables mobile devices to support 
advanced graphics. Both OpenML 1.0 
SDK and OpenGL ES 1 .0 are royalty- 
free downloads for developers. 
www.khronos.org 

Discreet announces 3DS Max 6. Discreet is 
planning a fall release for 3DS Max 6, 
the latest version of its 3D modeling 
and animation software. New features 
include advanced schematic view, inte- 
grated Mental Ray rendering software, 
vertex color painting, interchange sup- 
port with CAD tools, distributed net- 
work baking, a particle flow system, 
and other enhancements. 3DS Max 6 
will be available this fall for $3,495. 
www.discreet.com 



Trek films and television shows with 
that of Activision's Star Trek games. 
Activision's current Star Trek title is 
Ritual's Star Trek Elite Force II. 

SEC investigates U.S. videogame publishers. 

Acclaim, Activision, Midway, and THQ 
filed reports indicating that they are under 
investigation by the Securities and 
Exchange Commission (SEC). None of the 
companies has been formally accused, 
although the companies' filings indicate 
that the investigation is "focused on cer- 
tain accounting practices common to the 
interactive entertainment industry, with 
specific emphasis on revenue recognition." 

Nintendo forces pirates to walk the plank. In 

a Hong Kong court, Nintendo won a 
HK$5 million (U.S. $641,000) judgment 
against Lik Sang, which made a device 
that enables the piracy of Game Boy 
software. 

Send all industry and product 
release news to news@gdmag.com. 

UPCOMING EVEN T*S N \ 




XTREME GAME DEVELOPERS 
XPO 

The Westin Santa Clara 
Santa Clara, Calif. 
September 6-7, 2003 
Cost: $299-$359 

www.xgdx.com 

AUSTIN GAME CONFERENCE 
Austin Convention Center 
Austin, Tex. 

September 11-12, 2003 
Cost: $85-$125 
www.gameconference.com 

PROFITABLE MOBILE GAMES 
Le Meridien Waldorf 
London, U.K. 

September 29-October 1 , 2003 
Cost: £399-£1,099 (+VAT) 
www.totaltele.com/conferences/ 
mobilegames 
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DarkBASIC Professional 

by justin lloyd 




arkBASIC Professional is 
a modern, structured 
BASIC dialect with a lot 
of commands specifically 
for handling games using 
DirectX. It's capable of turning out a 2D 
platformers and 2D shooters as easily it 
handles 3D first-person shooters, both 
indoor and outdoor; in other words, any- 
thing you can create in C++/Win32/ 
DirectX, though the learning curve is shal- 
lower. An ideal scripting language for 
game designers and game programmers in 
a rush to try out a new idea, DarkBASIC 
allows you to get something up on-screen 
quickly and with minimum fuss, and from 
there take it all the way through to con- 
clusion, including burning the gold master. 

Unlike previous versions, the current 
release is a native Windows IDE that pro- 
vides an editor and integrated compiler. 
The editor is reasonably well featured but 
is still primitive in places. The IDE is capa- 
ble of its designed task, but little more. It 
handles multiple source files, assets, ver- 
sion numbering, and a TO DO list. 

The BASIC compiler turns out real 
machine code, and an included source- 
level debugger provides basic features — 
such as breakpoints — plus single-step 
and variable watches, both auto-scope 
and user-defined. The compiler turns out 
standalone executables with the ability to 
bundle any additional DLLs and assets 
into a single executable file, and it also 
removes any unused portions of the 
DarkBASIC libraries. Once the exe- 
cutable is generated (with or without 



DBProDebugge 



Command Line Interface Variable Watcher Step Through Mode 
- : Ecs.s S'-.y.c-e "'■;•< Basi ^ | Stop Prog 



Rem Project: RoomDemo 
Rem Created: 30/07/2002 17:17:07 
rem Hours: 20 

rem Initialise 

sync on : sync rate SO : hide mouse : backdrop off 

image colorkey 0.0.0 
set text font "Verdana" 
20 

rem Global data 
global ambienceft as integer 
global blockobj as integer 
dim objtype(10000) 

rem Make Hero 
gosub _make_hero 

rem Make Room 
gosub jireatejiglnts 
gosub _make_room 

rem Start things off 
gosub _start_demo 



rem Control Hero 
gosub _control_hero 





USE ARROW KEYS TO MOVE AROUND 



A screenshot showing DarkBASIC Pro's debugging feature. 




bundled assets), it can be automatically 
compressed and encrypted to create 
smaller and more secure distributables. 

Graphics capabilities. DarkBASIC is cre- 
ated specifically for manipulating the 
DirectX API in a simple and easy way. It 
handles all of the DirectX 8.1 features, 
providing ample facilities for 2D — using 
the DirectX sprite interface — and 3D 
graphics, plus input and audio. Initiali- 
zation of a full-screen or windowed 
DirectX application is as simple as either 
setting the startup options in the project 
explorer or issuing a BASIC command that 
dictates screen resolution along with win- 



JUSTIN L L O y D I Justin has over 1 8 years of commercial game programming experi- 
ence on almost every released platform. 



dowed or exclusive mode. The project set- 
tings also control the type of executable 
that is created — whether it is standalone 
or a Windows installer. 

The 2D sprite system is very capable, 
handling animations, movement, and col- 
lision between sprites. The 3D side is an 
even more comprehensive command set 
for graphics and math, covering vectors, 
matrices, Catmull-Rom and Hermite 
splines, plus all the usual trigonometry 
commands found in other modern BASIC 
dialects. The 3D graphics handle the 
usual rendering of polygons, loading of 
3D objects from disk, and creating primi- 
tives at run time, plus commands to con- 
trol the individual joints on a boned 
object and real-time mesh deformation 
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with direct support for a lot of popular 
model formats, including Quake 2 and 3, 
Half-Life, DirectX, and 3DS Max. 

Advanced texturing and rendering 
techniques using bump-mapping, envi- 
ronment mapping, and multitexturing 
give the shine to games, along with sup- 
port for hardware shadows, vertex and 
pixel shaders, and even a built-in cartoon 
shader. Rounding out the graphics capa- 
bilities is a general-purpose particle sys- 
tem with specific support for the unique 
properties of snow and fire particles. 

Camera control allows for multiple 
simultaneous cameras for multi-viewport 
rendering to either the back buffer or a 
bitmap. A camera is moved around 
dynamically via code or the tracking fea- 
ture that makes it follow another object. 
One of the nice features of the camera 
controls I explored was the intelligent nav- 
igation. By placing invisible static collision 
boxes in a scene, the camera will attempt 
to avoid entering the boxes. Scene lights 
are fully controllable, generated either in a 
level editor or dynamically at run time, 
with commands for spot, point, and ambi- 
ent, along with control of fogging distance. 

Object collision detection is handled 
automatically, and once a collision has 
taken place, DarkBASIC can either auto- 
matically move the colliding objects apart 
or leave it up to the programmer to deter- 
mine the exact outcome. The collision 
command set provides raycasting tests for 
user-determined collisions and probing. 

DarkBASIC renders indoor and out- 
door 3D scenes equally well with PVS 
and BSP support and a capable terrain 
engine that loads BSP worlds, handling 
the culling, texturing, and collision auto- 
matically. There's a bundled BSP compil- 
er that's installed with the IDE, and a 
programmer can generate dynamic ter- 
rain from height map files at run time. 

Other features. Beyond the graphics 
features, provision is made for input from 
keyboard, joystick/joypad and mouse, 
along with force-feedback capability. 
There are also extensions available for 
free from the DarkBASIC support web site 
that interface with a VR glove and USB 
light gun. The language provides strong 
audio support: streaming CD audio, MIDI 



and MP3 playback for music, and WAV 
and other formats for the sound effects, 
all of which can be processed as 3D posi- 
tional audio. It is also possible to capture 
directly from the microphone, useful for 
networked games. Video, either from an 
AVI/MPEG file or DVD can be mapped 
on to a texture in real time and then 
wrapped around an object. 

DarkBASIC features two command sets 
that deal with network communication. 
The first is for accessing FTP sites where 
you can retrieve or store any data you 
want — this feature can be used for send- 
ing high scores to a remote server, down- 
loading the latest patch or level pack for 
an established game, or even automatical- 
ly upgrading the game from unregistered 



DARKBASIC PRO kkkk. 



O STATS 

Game Creators Ltd. 
Wigan, Lancashire, U.K. 
Fax: +44 (0)8451 275 338 
www.darkbasic.com 

PRICE 
$99.99 

SYSTEM REQUIREMENTS 

Recommended: Pentium III 733MHz or 
above, 128MB RAM, DirectX-compatible 
graphics card with at least 32MB RAM 
and hardware 3D acceleration. DirectX 
compatible sound card, 16x CD-ROM, 
400MB hard drive space 

OPROS 

1. Simplifies access to all aspects of 
DirectX. 

2. Allows you to quickly get an idea up and 
running. 

3. Once the framework is in place, design- 
ers can treat it just like scripting. 

OCONS 

1. Requires CD or USB dongle to be insert- 
ed in the machine at all times. 

2. Can be clumsy to express some ideas 
due to lack of object-oriented features. 

3. Lack of professional production features 
could make it difficult to integrate in to a 
professional development environment. 
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excellent 
very good 
average 
disappointing 
don't bother 



to registered. The other command set 
handles multiplayer games via LAN or 
TCP/IP using a peer-to-peer or client/serv- 
er architecture. 

Documentation and Help. The spiral- 
bound manual covers the BASIC com- 
mand set, divided so that it deals with a 
specific area: 2D sprites, 3D objects, vec- 
tors and matrices, memory manipulation, 
and so on. Each BASIC command is given 
a brief paragraph of information and the 
syntax required. The manual does have a 
few weaknesses: For one thing, it doesn't 
supply brief examples of how to use com- 
mands. Often many commands will work 
in conjunction, and the user must infer 
how they bolt together. Many, but not all, 
of the commands are covered in the 
online examples replete with source code, 
and the online help provides more com- 
prehensive information with small code 
snippets. I don't see the need for the phys- 
ical manual — either bring it up to the 
level of the online documentation or 
abandon it all together. 

Last word. DarkBASIC is a great tool 
for developing both complete games and 
quick mock-ups, yet it has been over- 
looked by many professional game devel- 
opers who couldn't imagine that BASIC 
could be up to the challenge of creating a 
modern game with sophisticated graphics. 

The company announced it was about 
to post a public beta of DarkBASIC 5 on 
their web site, which will have many 
improvements, including support for the 
.FX shader format, and pixel-accurate 
selection of objects during gameplay. 

Right Hemisphere's 
Deep Paint 2 

by sean wagstaff 

Rather than trying to compete with 
Photoshop head-on, Right Hemi- 
sphere has wisely set up Deep Paint as a 
companion to Photoshop and has 
included import and export functionali- 
ty, along with a Photoshop plug-in that 
lets the two work together. As a result, 
you can paint with Deep Paint's unusual 
depth-mapped brushes, while retaining 
the fine control and extensive tools of 
Photoshop. 
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Deep Paint 3D s user interfaces allow artists 
to customize their textures and brushes. 

Version 2 of Deep Paint introduced a 
number of useful new features, including 
greatly enhanced cloning tools for painting 
based on the underlying pixels in imported 
layers, and spline tools that can be used 
for accurately creating masks or for creat- 
ing stroke paths for various brushes. 

Chief among Deep Paint's unusual fea- 
tures is the capability to paint with tex- 
tures, including bump mapping and spec- 
ularity, in addition to using basic colors. 

Game artists will appreciate the capa- 
bility to create their own texture brushes 
by creating their own sets of color, 
bump, specular, and alpha maps, and 
then using these brushes to paint the tex- 
tures into an image. 

In addition to texture brushes, Deep 
Paint does an impressive job of simulating 
wet and dry paints that mimic real-world 
materials, including thick, gooey oil paints 
and other materials where depth and spec- 
ular shine are an important element. 

Deep Paint has always let you set light- 
ing that is automatically rendered on the 
bump-mapped surfaces of your painting, 
and you can choose to retain this rendered 
lighting for use in your textures, or to omit 
the feature if your rendering engine is going 
to use the bump maps you've created. 

Typically, the texture-mapping work 
flow involves exporting UV maps to an 
image file and then painting over these 
maps to achieve the desired texture. Deep 
Paint's texture brushes make this easy, 
although unlike Deep Paint 3D, the 2D 
version has no 3D object painting fea- 
tures of its own. 

I was impressed with Deep Paint's abili- 
ty to render realistic-looking alpha-, 
depth-, and specular-mapped textures in 



2D paintings, but for game artists, Right 
Hemisphere could add a number of fea- 
tures to make it more useful. Primarily, 
the software needs the capability to view, 
edit, and export the underlying effects 
channels that control these effects. Even 
for 2D artists who simply want deeper- 
level control over their images, more con- 
trol over the underlying channels would 
be a good thing. I'd also like to see a 
wrap-around feature in the brushes that 
would let us paint textures that automati- 
cally tile seamlessly. 

Deep Paint 2 is available for Windows 
98/NT 4/2000/XP for $249 ($49 for an 
upgrade). As an add-on to Photoshop, it's 
a valuable addition to the creative toolbox. 

J^^^^ | Deep Paint 2 
Right Hemisphere 

www. righthemipshere. com 

Sean Wagstaff is a freelance 3D model- 
er. Contact him at sean@wagstaffs.org. 

Advanced 3D Game 
Programming with 
DirectX 9.0 

by Peter Walsh and Adrian Perez 

reviewed by jeremy jessup 

Peter Walsh's Advanced 3D Game 
Programming with DirectX 9.0 cov- 
ers a broad range of subjects critical to 
making games: graphics, artificial intelli- 
gence, networking, and mathematics. 
Priced at $60, the book contains 11 chap- 
ters that span approximately 520 pages. 

"Windows," the first chapter, describes 
how to create a window and respond to 
some of the common Windows messaging 
events. The chapter defines several custom 
classes that loosely resemble code created 
by Visual Studio's workspace wizard but 
cleaner and with a Win32 flavor. These 
classes form the framework for a generic 
Windows game. 

The next three chapters ("Getting 
Started with DirectX," "Directlnput," 
and "DirectSound") show how to com- 
pile and link DirectX with your applica- 
tion and initialize two of the subsystems 
found in DirectX, DirectSound, and 
Directlnput. The Directlnput and 
DirectSound chapters focus on initializa- 



tion rather than exploring the more 
sophisticated uses of each system such as 
force feedback or dynamic audio mixing. 

Chapters on 3D math, artificial intelli- 
gence, and networking follow. The math 
chapter provides basic math definitions 
including the dot and cross products as 
well as container classes for vectors and 
matrices. The AI chapter is brief; readers 
seeking to gain a deeper understanding 
should read the chapter in conjunction 
with a decent college text that describes 
fundamental search routines such as A* 
or Djkstra's algorithm. Finally, the net- 
working chapter relies on WinSock with- 
out mentioning DirectPlay. While all three 
chapters are essential to game program- 
ming, given the space provided, none of 
them adequately covers the complexity 
and nuances of each subject given. 

The rest, and the best, of the book dis- 
cusses rendering. Beginning with lighting 
and fog parameters, Walsh explores sever- 
al sophisticated graphics techniques 
including the mathematics of animation, 
subdivision of surfaces, radiosity, and pro- 
gressive meshes. Examples of multipass 
texture mapping are provided to illustrate 
various DirectX render states, but despite 
featuring DirectX 9.0, many of the new 
SDK features — such as vertex and pixel 
shaders — were missing from the text. 

Sample code is available online, but 
upon dowloading and trying to run them, 
three of the four programs crashed and my 
computer needed to be rebooted. 

Overall, this book's title is at odds 
with the subject matter. It provides an 
overview of the basic theory, API calls, 
and usage, but instead of offering more 
details, the reader was often referred to 
the DirectX SDK help. As an experienced 
game developer, I found very little of 
value in this book. None of the topics are 
explored adequately, leaving the seasoned 
reader with nothing but an unsatisfying 
overview and possibly a reference to the 
DirectX SDK help file. # 

| Advanced 3D Game Programming 
with DirextX 9.0 | Wordware 
www.wordware.com 

Jeremy Jessup has been developing games 
professionally for nearly five years. 
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Life in Camelot 



Mythic's Mark Jacobs on MMORPGs and the Self-Publishing Gamble 




ark Jacobs has been cre- 
ating pay-per-play games 
since 1984, with the 
release of his Dragon's 
Gate MUD. From that 
day on he has kept his main goal of "cre- 
ating an [MMORPG] that will encompass 
all relevant media" front and center in his 
game development plans. 

Co-founding Mythic Entertainment in 
1995 with the prime goal of providing 
online entertainment to mass audiences, 
Mark's vision has come very close to reali- 
ty. Mythic's Dark Age of Camelot took 
18 months from concept to a self-pub- 
lished release, and has become one of the 
biggest MMORPG success stories. The stu- 
dio is gearing up to start work on a new 
MMORPG title, Imperator, which takes place in a universe 
where the Roman Empire never fell. 

In a development world where self-publishing a AAA game 
is becoming increasingly rare, Game Developer spoke with 
Mark about taking control of a company's destiny. 

Game Developer: Dark Age of Camelot is one of the few very suc- 
cessful MMORPG titles. In your opinion, what about the game 
makes it stand out from others in the genre? 

Mark Jacobs: First, we had a very stable launch. With mini- 
mal downtime (due to crashes, updates, and so on), rock-solid 
servers, and a stable client, we were able to build on the ini- 
tial demand for the game. Second, we were — and remain — 
the best implementation of a combined PvE/PvP system to 
date. Third, we had the broad appeal of the Camelot legends 
to draw on. Finally, Mythic is committed to making DAoC 
the number-one MMORPG in the industry, which has allowed 
us to have a high conversion rate (the number of players who 
become subscribers) and retention rate (how long players stay 
as customers). While other developers say this too, we have 
backed this up with spending a ton of money on improving 
the game through both subscription-based updates and retail 
expansion packs. 

GD: How many teams does Mythic currently have working on 
titles? Do these teams collaborate on different projects? 

MJ: Right now we have one full team dedicated to improv- 
ing DAoC. While there are two components to that team 
(expansion and live), they are treated as one. When we begin 
work on Imperator, our newest MMORPG, some people will 
work exclusively on that game, but others will work on both 



Mythic's own King Arthur, Mark Jacobs is 
ready to face new challenges on the 
MMORPG front. 



games at once; thus, as we add things for 
Imperator, many of the applicable improve- 
ments will also go into DAoC. We are also 
in the process of hiring new people to add 
to both DAoC and to Imperator. 

GD: How long did it take between DAoC's ini- 
tial development and the signing of your first 
player? How has that differed from past devel- 
opment schedules and why? 

MJ: In the past, Mythic had anywhere from 
six to nine months to create a game. Taking 
18 months, DAoC was the longest develop- 
ment cycle ever for us, the reason being that 
for the first time we actually had enough 
funding to develop a top-quality game. 

GD: Mythic self-published Dark Age of Camelot 
(with help from Abandon). Going into that deci- 
sion, what were your expectations about the 
process and what turned out to be the reality? 

MJ: We knew there would be a host of problems associated 
with the release, but that if we did our jobs everything would 
be fine at the end (or at least that's what we told ourselves). We 
ran into very few unexpected problems, and for the most part 
the reality — other than the exceedingly large demand for the 
game at launch (the number of subscribers we got in the game's 
first week was what we had projected for the first month) — 
was exactly what we were expecting. Luckily, we have been 
extremely successful and are, for the first time, able to be in 
control of our own development path for the foreseeable future. 

On a personal level, my expectations were that if DAoC 
failed, my next job would involve hairnets, nametags, and the 
phrase "Would you like fries with that?" 

GD: Without Abandon's financial investment early on in the 
game's development, how close were you to that scenario? 

MJ: We would not have been able to create Dark Age of 
Camelot without Abandon's investment. They acted as a co- 
publisher for us then. If we hadn't had that investment, we 
would have been in a very tough position. 

GD: Say my studio is considering self-publishing our next title. 
What scorecard should I use to assess if this is a viable move or not? 

MJ: First, make sure that you are realistic in setting the 
development schedule. Second, once you set the schedule, add 
at least 25 percent to it (give or take a certain amount based 
on how many other games you have done). Third, make sure 
you have enough money to cover this new schedule. If you 
can't cover your finances, you shouldn't be self-publishing, 
especially if it's your studio's first game. 
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Using an 

Arithmetic Coder ■ Part 2 



n a client/server game system, we want to transmit as 
much data as we can through a limited amount of 
bandwidth. An example of such data would be the 
server telling the client the states of all objects in the 
world. Last month in "Using an Arithmetic Coder: 
Part 1" (August 2003), we saw how an arithmetic coder can 
help us efficiently pack data values into network messages at 
sub-bit precision. This system produced no gaps between the 
individual values, which saved space, especially when values 
were small. 

But if we want bigger space savings, we might compress the 
transmitted data outright. We could do this with a relatively 
brute-force approach, such as linking the free "zlib" compres- 
sion library into our game, sending it our network messages as 
arrays of bytes, and telling it to compress those arrays. There 
are a lot of reasons why this isn't a good idea, some of which 
will become clear as I discuss alternatives in this column. 

Arithmetic coders are great at compression, and there are 
some excellent references — such as the CACM87 paper — that 
explain the basics of arithmetic coding compression (see For 
More Information at the end of this column). Here I'll try to 
provide some alternative views not found in the references. I'll 
also discuss ways we as game programmers need to approach 
arithmetic coding differently from the mainstream. 

Probabilities 

Just like last month, we encode a message by mapping it to a 
small piece of the interval [0, 1). Compression occurs by 
transforming values so that common values take up large pieces 
of the interval, and rare values take small pieces. The ideal 
amount of space that any value or message can be compressed 
into is -log 2 (p) bits, where p is the probability of that message. 
Don't be confused by that negative sign; since p is always in [0, 
1) by definition (it's a probability), the log always produces a 
result that is negative or zero, and the negative sign just revers- 
es that. In Figure 1, I've tried to illustrate why it takes fewer 
bits to encode a bigger subset of the unit interval. You can 
think of the active principle as "The smaller something is, the 
more precisely you must describe its location in order to guide 
someone to it." 

Starting with the interval [0, 1), for each value we want to 
pack, we pick a fraction of the current coding interval that's 
equal to that value's probability and shrink the coding interval 
to that new subset. Last month, in order to pack a value into a 
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FIGURE 1A. The unit interval divided into two equal pieces, spanning [0, 
1/2) and [1/2, 1). To specify one of these pieces, we only need one digit 
after the point. Binary .0 (0 decimal) indicates interval L, since any 
number starting with .0 lands in the range [0, 1/2). Likewise, .1 is suffi- 
cient to denote R, since any number starting with .1 lands inside R. 
FIGURE 1 B. Interval R has been subdivided. The number .0 is still suffi- 
cient to specify L. However, .1 now could indicate any of the three inter- 
vals on the right; we need more digits to specify which. 

message, given n possibilities for the value, we would just sub- 
divide the current coding interval by n. That's the same as treat- 
ing all the possibilities as though they were of equal probabili- 
ties. So essentially, this month we're just going to improve our 
model of the data's statistics. 

Conditional Probabilities 

Figure 2 shows two different illustrations of this process of 
encoding a string of values. Figure 2a illustrates the recur- 
siveness of the concept, showing how we zoom in on one tiny 
piece of the unit interval. Figure 2b takes a more aloof view- 
point, looking at the set of all possible messages we could 
transmit and their relative probabilities. It's a little more clut- 
tered, but it's useful because it helps clarify some aspects of 
message probabilities. 

To get the best compression, we want to look at the set of 
all possible messages we could transmit and ensure that each 
of those messages maps to a piece of the unit interval of the 
exact size dictated by its probability. Our goal is to compute 
P(y o = k Q , y 1 = k x , ... , y n = kj, the probability of the final 
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composite message. If the y. are statistically independent, the 
compound probability just becomes the product 
P(y o = k Q )P(y 1 = k x ) ... P(y n = k n ), and the answer is simple to 
compute, since we don't need context around any single value. 
But this criterion of independence almost never holds. 
Thinking of this probability as being a divisible and well- 
ordered thing is probably a mistake. Certainly nothing in real- 
ity limits the dependencies to flowing forward along with our 
indices on y. For a particular problem, we might need to com- 
pute P(y 3 = k 3 I (y 5 = k 5 , y 9 = k 9 ) , ... , y 1 = kj, and that is still 
a tremendously simplistic way of looking at the problem. 

I bring this up in such an annoying fashion because data 
modeling for arithmetic coders is usually explained the way text 
compression people see the problem. In that paradigm we have 
a bunch of uniformly sized symbols, and we run through some 
example data to build tables giving us a Oth order or 1st order 
or nth order model of the data, which we then use for compres- 
sion, perhaps adaptively. I find this mode of thought limiting 
when it comes to approaching general problems. As an exam- 
ple, Claude Shannon, the father of information theory, did a 
number of experiments to compute bounds on the actual infor- 
mation content of the English language. The results of these 
experiments can tell you approximately what compression ratio 
you'd get out of a very good compressor. Shannon found an 
upper bound of about 1.3 bits per character and a lower bound 
of half that; these numbers are much lower than the ratios 
achieved by the current best compressors. (For some example 
compression statistics, see Charles Bloom's web page in For 
More Information.) Evidently, given an AI that understands 
English as well as a human, you could use its predictions of 
upcoming text to build a much better compressor than we cur- 
rently know how to make. 

Such an AI would perform well because it contains much 
knowledge about the behavior of English. This is not strictly a 
model of the way letters tend to follow each other in text; on a 
deeper level it's a model of what the author of the text was try- 
ing to accomplish by writing the text. Actually, it's even deeper 
than that: it's a model of the kinds of ways people tend to 
behave, allowing us, upon encountering a text, to generate a 
more specific model of what the text is intended to achieve. My 
point is this: Any knowledge you can exploit to predict the 
probability of a message is fair game. It doesn't have to be 
information actually contained in the message. 

Sample Code 

This month's sample code (which you can download from 
the Game Developer web site at www.gdmag.com) is a file 
compressor. And to compress files, we will use only information 
contained within the files. But this is all because the code is 
written to be as simple as possible, to be easy to understand 
and build on. It provides two options for compression: order 
modeling (no context around each character) and order 1 mod- 
eling (one character of previous context is used to guess the 
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FIGURE 2. Suppose we create a message by packing together two vari- 
ables v and v r each of which can take on the values 0, 1 , or 2. Figure 
2A shows the process of finding the appropriate piece of the unit inter- 
val, for the case when v =1 . Figure 2B shows a bird's-eye view of all 
message possibilities. 

probability of the current character). The code reads from an 
example English text file in order to build a static probability 
model for the expected data. It then uses that model to com- 
press a different file. 

Most arithmetic coding text compressors use adaptive 
modeling, but this one does not. Adaptive modeling is a 
method of modifying the probability tables to fit the file's 
usage patterns, as pieces of the file go streaming by. The nice 
thing about this method is that you don't need to store any 
probability tables; you just start the encoder and decoder in a 
context where all values are equally probable, then you just 
let them go and adapt. Arithmetic coders are ideal for adap- 
tive modeling, which is one reason why people like arithmetic 
coders so much. 

Unfortunately, in a high-performance networked game, adap- 
tive modeling is not as straightforward as it is for a file com- 
pressor. Because the probability tables are implicit, the decoder 
needs to see the entire stream transmitted by the encoder. But in 
a networked game, we need to drop network messages or 
process them out of order. An adaptive decoder could not do 
this, as its probability model would fall out of synch with the 
encoder's, causing it to produce garbage. 

Next month, we'll look at a scheme for adaptive modeling in 
a client/server environment. But you may decide that the neces- 
sary complication is not worthwhile; if so, a static probability 
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model will still work for you. And thus, one of the primary 
purposes of this month's sample code is to provide a simple 
example of a static modeler. 

Last month's encoder used an integer divide once per packed 
value to compute the new coding interval. This month's code 
uses a bit shift instead, so it's faster in that sense. Because we're 
multiplying probabilities, and those probabilities are necessarily 
approximate (because we must fit them into a piece of a 
machine word), we can ensure that they're represented as frac- 
tions whose denominators are a known power of two. Round- 
ing the probabilities this way does distort them a little bit, 
resulting in a loss of compression efficiency, but that loss is so 
small as to be unnoticeable. 

Structured Data 

I ow I'll talk about some ways in which the data you really 
I want to transmit will differ from the sample code. 
Much real-game data will be hierarchical. For example, to 
represent a game entity, we may have one object class defini- 
tion per entity type; if the server wants to tell the client about 
this entity, it must transmit all the fields of that class defini- 
tion. Those fields might be { type = WIZARD, position = (x, y, 
z), angle = 1.12, health = 73 }. If we transmit two entities to 
the client, we make a message that looks like: [ WIZARD, (xl, yl, 
zl), anglel, healthl, BARBARIAN, (x2, y2, z2), angle2, health2 ]. 
Modeling this data as a linear sequence would be a mistake, 
since it's unlikely that the value of healthl is usefully correlated 
with the next value in the sequence, the entity type BARBARIAN. 

But we may wish to draw correlations between parallel fields 
(members of a party traveling together are probably near each 
other and are probably facing nearly the same direction). And 
we may wish to draw correlations between certain data fields 
and certain other protocol messages. Consider a "Drink 
potion" protocol message. If a character has low health and 
high mana and he drinks a potion, chances are good it's a 
potion of healing and not a potion of mana. Or, perhaps char- 
acters located near a town are usually drinking potions of 
speed, so that they can quickly leave the safe area and get to 
the fighting; but characters located out near the fighting are 
usually drinking potions of health and mana, and almost no 
potions of speed. 

Coherent Values 

This talk of position correlations brings up an important 
issue. As discussed last year ("Packing Integers," The Inner 
Product, May 2002), positions are generally transmitted as 
tuples of integers. Suppose I am camping with a party, and we 
are moving about healing each other and keeping watch for 
monsters. My current X position is 4,155 out of 10,000. (This 
is just an example and is likely to be too low-resolution a posi- 
tion for use in a real game.) Since I'm milling about, my next 
X position is likely to be near 4,155, but it probably won't be 



4,155 exactly. It might be 4,156. But a generalized data model- 
er, written in the way of file compressors, would treat 4,155 
and 4,156 as unrelated "symbols." An adaptive modeler, upon 
seeing the 4,155, would increase the probability of 4,155 com- 
ing again in the data stream, but implicitly this decreases the 
probability of seeing 4,156, thus hurting compression if I am 
moving at all. 

Because we move through space continuously, spatial values 
are correlated. There is a high correlation between 4,155 and 
4,156, because those points are spatially nearby. Thus when 
transmitting an X coordinate of 4,155, an adaptive modeler 
should actually increase the subsequent probability of all X 
coordinates in the neighborhood, using a Gaussian centered at 
4,155. Actually, we'd ideally want to intercorrelate X, Y, and 
Z, keeping the resulting probabilities in a 3D grid; this is 
expensive, though, and independent ID tables for each coor- 
dinate are almost as good in practice. (However, the higher 
the number of dimensions we work in, the worse this approxi- 
mation becomes, so be hesitant when using it for a high- 
dimensional model. This is related to the fact that as n grows, 
the unit sphere in n dimensions contains decreasing amounts 
of space compared to the unit cube.) 

I call this type of data a "coherent" value. Another example 
of a coherent value is health; if you are at full health and 
you're being attacked, your health will probably go down 
gradually. It's much less likely to drop instantly from high 
health to health. 

As I mentioned earlier, good compression is all about mak- 
ing accurate predictions. Predicting the change of continuous 
values over time has a history in online games; it's often 
known as dead reckoning. So as it happens, we want good 
dead reckoning not only to fill in the gaps between network 
messages, but to help encode and decode those messages too. 

Next month we'll look at a method of adaptive modeling 
designed to operate despite packet loss in a client/server envi- 
ronment. In the meantime, this month's sample code will get 
you used to the basics of data modeling, 
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X 5 Al1 Artists Should 

Things Know: Part 1 



t barely seems like yesterday that I sent off my first 
Artist's View column to the good people at Game 
Developer. But in fact, it's been 20 months since my 
stewardship of this column began. And what a long 
strange trip it's been. 
After much thought and deliberation, I have decided that the 
time has come to move on and hand the column over to whom- 
ever is crazy enough to take it. However, if you could pause 
from your celebrations for just a few minutes, I have some final 
things to say before I go. 

Thinking about the most suitable way to end my tenure, I 
put together a summary of the 15 most useful things I have 
learned over my years in the game industry. They are presented 
this month and next in no particular order except numerical, 
with the hope that someone might be able to find something 
genuinely helpful among the meandering analogies. 

All artists are telepathic. At some point many 
# years ago, from a place deep within the game 
development community, this insidious rumor sprang to life. 
Growing in popularity over the years, especially among com- 
pany owners, producers, and project leads, it became an 
accepted truth that all artists could read the minds of those 
who controlled the games they were working on. 

The phrase "You need to make a futuristic military strong- 
hold" soon became the sum total of all design input from above, 
and the artist-telepath was then required to use his or her pow- 
ers to discern exactly what that meant: from the overall size 
right down to the color of the ceiling tiles. Some artists began to 
believe that they did indeed have the power of telepathy, but 
time after time discovered the harsh reality of their mistake as 
they were told, "No, that's not really what I had in mind." 

Despite the most strenuous efforts of artists over the years, 
there are many in positions of control within a project who to 
this day find it difficult to understand that vague instructions 
will always lead to a specific end result, and that this end result 
has absolutely no chance whatsoever of replicating the image 
they have in their head. 

While reworking content is always going to be part of the 
artist's job description, getting as many specifics pinned 
down in advance can help reduce the number of times that 
each item has to be revisited. This in turn increases produc- 
tivity while simultaneously reducing the chance of an artist's 
brain exploding. 




Id's upcoming Doom III utilizes lighting as an integral part of the game's 
atmosphere. 

4 Get the right light. High school art history classes 

A # bored me beyond my ability to express it ade- 

quately in words. I know that understanding the evolution of 
art can help artists find their own particular path to inspiration, 
but to be honest, once my art teacher opened the Black Book of 
Misery, which was imaginatively titled Art Through the Ages, it 
wasn't long before I found myself hallucinating about how easy 
it would be to end my suffering with the cunning use of two 
gallons of Quinacridone Red and a box of No. 2 pencils. 

However, regardless of my teenage inability to be interested 
in anything that didn't revolve around me (my wife thinks that 
this is still the case), I do recall being taught that many artists 
over the centuries have spent time working in specific locations 
entirely because of the quality of light to be found there. 

If you have done much work outdoors (sketching, painting, 
photography) you have doubtless felt the forceful hand of 
nature slapping you around by dictating how an entire scene 
will look with a simple shift in the lighting conditions. 
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In the world of high-end computer graphics, perhaps the 
biggest improvement in recent years (in terms of realism at 
least) has been the advancement of highly complex lighting 
systems that distribute light more accurately, moving away 
from the the arithmetic cleanliness of Tron to the plastic ren- 
dering of Babylon 5. 

Likewise, real-time graphics have also advanced in the quali- 
ty of lighting available, and just like in the great outdoors, a 
game's visuals can be made or broken by the quality with 
which the available lighting technology is implemented. 

Having covered lighting before and as there are many sources 
to consult about success in this area, my point here is simply 
that a game's visual design must also include lighting design to 
maximize its appeal. Too often light is an afterthought or is sim- 
ply a means of making the characters and scenery visible to the 
player. However, light is central to how a game world looks, and 
as technology allows us to achieve more in this direction, we 
need to take maximum advantage. 

»Know what you've got and what you've not. Have 
% you ever wondered why Carl Lewis never compet- 
ed in the 3,000 meter event? He was one of the greatest athletes 
ever: a supremely fit speed machine. But, unless I am greatly 
mistaken, he never competed internationally in the 3,000 meters, 
or for that matter, the pole vault. 

As I sit in this chair having just eaten enough lemon cake to 
feed a family of 12, barely able to tie my own shoelaces without 
groaning like I was giving birth to a giraffe, I'm sure Carl Lewis 
could have run just about any distance he pleased and still have 
beaten me by an incredible margin. However, my inclusion in 
the British Olympic Team was unlikely. From Lewis's point of 
view, the class of athletes he would need to compete against 
would be somewhat higher, and so he restricted his participation 
to those events at which he excelled. 

Sure, the lure of being great at everything has to seem invit- 
ing to some athletes, but even decathletes have their weak 
events. When you want to be the best, specialization is the 
route to success. 

In game art, there are all sorts of platform limitations, engine 
limitations, software limitations, and design limitations restrict- 
ing your imagination and creativity. However, you probably 
have a few areas in which your game is particularly strong, and 
so your task is to try to think, from as early in the design 
process as possible, what to push and what to avoid. 

If your water is pathetic, keep it to a minimum. If your 
engine crumples and dies when faced with expansive areas of 
terrain, for the love of God, stay indoors. Designing the visuals 
to complement your technology is not a cop-out, it is just intel- 
ligent planning. 

More real than real. Photo-real, hyper-real, ultra- 
A ^fa % real, take your pick (or make your own word up 
if you like): since the early days, the quest for more realistic 
graphics in games has formed a large part of an artist's job. 



I vividly remember sitting in front of a TV screen in the early 
1980s, marveling at how real I thought the world that had been 
created by an 8 -bit computer seemed compared to the primitive 
blockiness of the Atari 2600. 

In computer graphics terms, realism is a relative concept, or at 
least it has been until recently. As far as I can be objective about 
it, we are beginning to approach the very minimum threshold of 
what can be called genuinely realistic in real-time visuals. 
Certainly in a decade's time, we will look back on 2003 and see 
it as painfully low-tech and angular, but to the casual observer 
some of our current games are knocking on realism's door. 

In the quest for photorealism, artists have long turned to the 
world around us for guidance. But like those involved in films 
have realized, we must learn when mere real-world material is 
not enough to provide the results we want. 

As in film, the game medium ultimately affects how things 
appear on-screen. An image that travels through a camera and 
is then transported by film to the cinema screen represents an 
altered version of the original scene. 
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Mike Tyson's Punch-Out!: A 1980s milestone in 
"photorealism" on home consoles. At the 
time, we thought that was pretty cool. 



In games, photo- 
graphic accuracy, 
such as physically 
realistic motion 
capture or lighting 
modeled faithfully 
on real-world read- 
ings, won't neces- 
sarily appear com- 
pletely realistic to 
the player. The 
human eye reads 
the real world in 
an entirely differ- 
ent way than it 
does a computer 
screen or TV. The absence of genuine depth perception, the 
inherently flat and generally small amount of screen space 
available, as well as the restricted color palette and range of 
light levels all try to convince the player that what they see 
isn't real. 

As a result, an artist has to learn to compensate for these 
obstacles by over-saturating colors when necessary, and 
upping contrast to bring out detail that would otherwise fade 
into obscurity. For example, the light that we think we see as 
white in the real world may need to be slightly blue on the 
screen. Animations that are entirely accurate may need to be 
exaggerated to help them make a convincing impact when 
they reach the player's brain. 



MThe Death Star Principle. Based on the execution of 
# the Death Star special effects for the original Star 
Wars trilogy, the Death Star Principle simply states: Only 
spend time putting detail where you need it. 

It's sometimes hard as an artist to create something that is 
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plainly unfinished when examined as a single object or environ- 
ment in isolation. But time and resources are rarely infinite, and 
artists must always focus their efforts in the areas that will have 
the most impact on the player. 

The Power of One. This is not an assertion that 
# you can single-handedly influence the course of 
your game by focusing all of your ninja powers on art, thus 
defeating the evil Publisher Hordes and freeing your game 
from its creative shackles. The Power of One is not about you 
at all, it's about the people to whom you report. 

Each company has its own unique management culture. At 
one place it may feel as if you are toiling under the iron fist of 
Stalin with the chill wind of oppression blowing around your 
CPU. At another company, it may feel as if you're working for a 
17-year-old whose parents have gone away for the weekend and 
have given him unrestricted use of their credit card. But whatev- 
er the situation, one of the most frustrating things you can 
encounter is the inability of many companies to decide who 
actually has the final say as to whether a particular art asset is 
acceptable or not. 

Some companies (particularly those with overly complex 
management systems) have a whole batch of people in "execu- 



tive" positions who all believe that their input and instructions 
need to be followed. From creative directors, art leads, internal 
and external producers, all the way to company accountants, 
marketing staff, investors, and the owner's mother-in-law, 
internal politics and the belief that seniority should automati- 
cally mean control in any area of the project can quite easily 
drive an artist to an early grave. 

The easiest solution to this problem might be to go work for 
yourself, but as this is seldom practical (never less so than at pres- 
ent), how else can you improve things in this respect? Unfortuna- 
tely, there is no easy answer. The more junior your position, the 
more likely you are to be affected by this kind of situation and the 
less chance you have of having any influence over it. 

Pointing out this conflict of leadership will in some cases help 
get things straightened out so that they are less confusing. How- 
ever, in certain circumstances, this will just exacerbate power strug- 
gles, placing you awkwardly at their center. One method that sim- 
plifies the situation is to request being assigned a specific person, 
whatever his or her title may be, to whom you report, and who 
has the authority to sign off on the work that you do. This needs 
to be one person and not a committee, and if a committee is 
deemed necessary, then just one of the people involved should be 
responsible for dealing directly with you. 

This may seem to be a superficial solution that doesn't actu- 
ally address the root of the problem. But assuming that you are 
not in a position to tell the management exactly how annoying 
their methods are, attempting to isolate yourself from all but 
one of them is a step in the right direction. 

The real difference, however, has to be made by those who do 
in fact make the decisions. Be mindful of how things are organ- 
ized and streamline the chain of command as much as you can. 

9 1 see triangles everywhere (OCTD). Do gastrointestinal 
# surgeons walk down the street and visualize the intes- 
tines of the people they pass? Are architects compelled to ana- 
lyze every building they see in terms of their design and fabrica- 
tion techniques? The reason I wonder is that almost all the 
artists I know in the game industry have, at one time or another, 
caught themselves looking at a bridge and thinking, "I could do 
that in 150 polys." 

Obsessive-Compulsive Triangulation Disorder (OCTD) is 
commonplace among 3D artists and can be a good indication 
that the infected person needs to get out more. Artist burnout is 
a real problem that can arise when either extremely long hours 
are maintained for unreasonable periods or work isn't varied 
enough to allow the artist a change of focus every so often. 

Circumstances can sometimes dictate less-than-perfect work- 
ing conditions, but it is certain that artists will not produce 
excellent work if they begin to show signs of this kind of 
fatigue. A sensible project lead will see that in the longer run, 
more can be achieved at a higher level of quality if the workload 
is organized to take fatigue and burnout into consideration. 

Next month: The remaining eight things that all artists 
should know, and a final farewell. "& 
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SOUND PRINCIPLES 



a d a m I e v e n s o n 



One Man's Foley 

Is Another's FX Nightmare 



e've chosen you to 
make our game 
audio shine." Isn't 
that phone call one 
of life's most glori- 
ous moments? So glorious that sometimes 
we lose ourselves in the moment, the 
moment when we should be listening 
because the guy on the other end of phone 
says something that makes a little voice 
deep inside you scream, "Don't take this 
project!" Whether you're in-house, out-of- 
house, or working out of your own house, 
a promising project eventually will come 
up that will have a huge red flag draped 
all over it. Too often, however, we ignore 
this red flag until it's too late. To prepare 
us better, here are some warning signs to 
take heed of before accepting an offer. 

That F-word. In the game world, we've 
adopted the term "foley" to refer to 
movement-related effects. Sadly, it has 
become one of the most abused terms in 
our industry and a real red flag catcher. If 
a producer calls up offering you the big 
gig, but says something like, "When the 
mega-laser gun fires the protoplasmic 
mega shot, we gotta have some really cool 
foley," watch out. When your contact 
starts talking gibberish, ask yourself 
whether he or she is making an accidental 
malapropism or covering up a lack of 
game audio knowledge by repeating buzz- 
words overheard elsewhere. Misused ter- 
minology could be a warning sign that 
your contact lacks an understanding of 
game audio. The confusion resulting from 
this ongoing miscommunication could 
pave a long, bumpy road. 

RAM abuse. You've put hours of work 
into a complicated bid — a console title 
requiring tons of effects, ambiences, and 
yep, even foley. The phone rings. "We've 
looked at a bunch of talented sound 
shops, and, well, you're the one. Make us 
proud!" You want things to start off right, 
so while the party balloons are still float- 
ing, you pop the burning tech question: 
"Gee, with so many effects, I bet we're 
going to have some fun designing a 



dynamic caching system together with 
multiple primed streams and real-time 
sound mixing." Silence on the other end, 
then, "Look, this is really a simple game, 
and we're just going to downsample 
everything to 11K and shove it into 
RAM." Uh-oh. Technology drives great 
sound, so when a console game is made to 
use RAM like an audio CD, or when a PC 
game developer insists on using all MP3 
compression at 96 kbps, you have to 
decide if you really want to make a game 
that you know isn't going to sound great. 

The dreaded response: "Look, 
we've got a milestone coming 
up in about a week. We just 
need the sounds." 

Give me SFX. Back in the old days, 
before game developers got hip to post- 
production techniques, most game audio 
folks made sounds in the abstract, sepa- 
rated from the visuals, and then a pro- 
grammer (usually in a bad mood) would 
pair up the audio with the visual event. It 
was guesswork. Sadly, some people are 
stuck in a time warp and still think we 
work this way; the worst incarnation of 
this problem is the infamous "Just make 
some sounds. Here's a list." 

"But, what about the visual reference?" 
you protest. "You know, sync?" And then 
the dreaded response: "Look, we've got a 
milestone coming up in about a week. We 
just need the sounds." 

The only result from this production 
method is failure. You can't make quality 
commercial entertainment by throwing 
together disparate parts and hoping they 
miraculously come together. 

The art of diplomacy. Instead of running 
full speed for the door the minute you 



hear any of the preceding remarks, how 
can you turn things around to salvage 
the project (and your sanity)? When deal- 
ing with something as complex and spe- 
cialized as sound effects production, you 
often have to be very understanding. 

Let's say you're faced with a studio that 
honestly believes a mono ambience is 
good enough for their game. It's time to 
trade in your well-worn audio cap for that 
diplomatic suit and tie hanging in the 
back of your closet. The three E's outline 
the basic steps to win them over: educa- 
tion, examples, and execution. 

Education. Using the mono ambience 
situation as an example, you might (gen- 
tly) explain that when one walks outside, 
sound is all around, that there is no sin- 
gle source for ambient sound, and there- 
fore it can only be truly re-created in a 
game using surround. 

Examples. Suggest a game or movie 
that utilizes ambient sound with great 
results. This gives people a tangible refer- 
ence, which is worth more than words. 

Execution. Now that you've persuaded 
them to see your point of view, you have 
to execute with two choices: prototyping 
or going straight to production. Either 
way, give them some impressive exam- 
ples, create trust between the two of you, 
and move on to the next issue. 

If it looks like you might be boarding a 
sinking ship, you've got to be polite and 
diplomatic, even in quitting. Create some 
good karma by passing the gig on to 
someone starting out in the business who 
needs the experience. This gives the pub- 
lisher a quick fix and the other guy a great 
opportunity. You've done a good thing 
and saved your reputation in the process, 
just in time to look for a new gig and start 
avoiding red flags all over again. 




ADAM LEVENSON I Adam is the former audio director of 
Interplay Entertainment Corp., and is currently the audio director 
of Immersive Sound (www.immersive-sound.com) . During his 
career Adam has worked on several award-winning titles. 
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BETTER BY DESIGN 



n o a h f a I s t e i n 



Trumping 

Consistency 



My June 2003 column, 
"The Hobgoblin of 
Little Minds," dis- 
cussed how to handle 
consistency in game 
design. It's a tough problem, because the 
simplest rule, "Be Consistent," has so 
many obvious exceptions that it's of 
minimal use, although clearly some 
degree of consistency is beneficial. The 
question becomes, "How do I define 
and implement consistency, and how do 
I know when I have the right amount?" 

An insight about it hit me while work- 
ing on a client's design. In this particular 
game, players control astronauts perform- 
ing experiments aboard a space station. 
We were stuck between wanting consis- 
tency or differences in the appearance of 
several different types of experiments, to 
either enhance or expand gameplay possi- 
bilities. Variety in gameplay — as well as 
fidelity to the way things work in the real 
world — felt more important than simple 
visual consistency, but I was curious to 
see if I could discover a governing rule. 

A previously published rule ("AI 
Without Pain," January 2003) suggested, 
"When simulating a real system, use real- 
world formulas and cheat as little as is 
feasible." I think this rule extends to 
interface as well. A possible consistency 
rule is "Be Consistent with Gameplay 
Elements." But in our interactive medi- 
um, gameplay considerations should gen- 
erally trump mere visuals, and so the 
question becomes, which gameplay ele- 
ments are important here? 

One possible answer comes from 
Stephen Triche, an IGDA member from 
Louisiana. He suggests trumping with a 
rule that limits excessive consistency 
when it renders the game too boring and 
predictable. That sounded familiar, and I 
realized that one of Hal Barwood's origi- 
nal rules from his 2001 GDC talk, 
"Four of the 400," was "Fight Player 
Fatigue." That rule is a perfect trump 
for consistency with both lower and 
upper limits. 
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Do these crates (from Ratchet & Clank) contain 
bonuses, bombs, or perhaps a few rules about 
consistency? 



Too much consistency means the 
player will be fatigued through repeti- 
tion, as when a character in a game 
repeats the same battle cry ad nauseam. 
But too little consistency fatigues the 
player through confusion and frustra- 
tion. For example, it's frustrating when 
a character ordered to move from point 
A to point B picks a random pathway 
each time and sometimes arrives too 
late, while at other times wanders into 
dangerous traps. 

I received some mail protesting my 
endorsement of Mark Cerny's suggestion 
about occasional random exploding 
crates, which I used to illustrate how 
lack of consistency can be useful. I don't 
mean to put words in Mark's mouth, so 
I'll take full responsibility to say that I 
like the idea but recognize why others 
may not. The safe solution would be to 
make exploding crates look slightly dif- 
ferent, so the first such crate a player 
triggers may be a surprise, but subse- 



quent dangerous crates can be detected 
and avoided. But "Fight Player Fatigue" 
is a good reason to have occasional 
exploding crates among many that mere- 
ly provide bonuses. 

This discussion raises the idea of con- 
sidering rules about applying rules. It's 
one of the reasons that The 400 Project 
includes the concept of rules trumping 
each other, as in this case where a previ- 
ous rule, "Fight Player Fatigue," acts as a 
sort of modifier for "Be Consistent with 
Gameplay Elements." Designer resistance 
to having exploding crates look just like 
the safe crates violates a rule I'll cover in 
a future column, "Play Fair." 

Overall, it's important to structure 
games so the player who faces a setback 
says, "Shoot, I messed up," and not, 
"Dang, that stupid game cheated me!" 
(Readers are invited to substitute suit- 
ably stronger language to preserve sus- 
pension of disbelief.) Having unmarked 
exploding crates does violate the "Play 
Fair" rule, but by doing so implements 
the "Fight Player Fatigue" rule more 
thoroughly. I've heard a few developers 
balk at the idea of using rules to help 
them design games because rules feel 
restrictive, but a case like this illustrates 
how rules can set designers free to 
choose intelligently. 

Ultimately, when rules conflict, it's up 
to the designer to choose among them. I 
prefer having a clear idea of the trade- 
offs instead of just a murky sense that 
one way may be better than another. To 
follow one rule consistently without con- 
sidering possible trumps would be foolish 
— and if you're a regular reader of this 
column, you know what Emerson said 
about foolish consistency. 0? 
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NOAH FALSTEIN I Noah is a 23-year veteran of the game 
industry. His web site, www.theinspiracy.com, has a description of 
The 400 Project, the basis for these columns. Also at that site is a 
list of the game design rules collected so far, and tips on how to 
use them. You can e-mail Noah at noah@theinspiracy.com. 
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TOP 20 PUBLISHERS 



t r i s t a n d o n o v a n 



Game Developer Reports: 





uch like the 
development sector, 
game publishing has 
changed irrevocably 
in recent years. 
Numerous mergers, closures, rebrand- 
ings, and restructurings have not only 
wiped away many of the big names of 
yesteryear but also sowed confusion about 
publishing's main players. 

Yet understanding these changes and 
what makes each publisher distinctive is 
vital for those working in development. 
Knowing what makes a publisher tick can 
play a big role in getting the best out of 
your business relationships. 

Awareness of a publisher's general atti- 
tude toward external development, its 
treatment of other developers, and what 
genres it concentrates on can be highly 
valuable when dealing with a publisher. 
Clearly, knowing who are the biggest pub- 
lishers in the market is also pretty handy. 



However, finding this informa- 
tion is no easy feat, so many devel- 
opers go without, which is why Game 
Developer has put together this unique 
guide to the Top 20 publishers. 

Over the next few pages, we profile the 
largest game publishers in the world, ana- 
lyze the types of games they release, and 
explore their relationships with external 
development studios. 

Among the information Game Devel- 
oper compiled for this report are details 
on each publisher's reliance on existing 
IP, what formats it concentrates on, and 
how much use it makes of external 
developers. On top of this, we reveal the 
results of an exclusive poll finding out 
how developers really felt about the pub- 
lishers with whom they worked. 

We hope this report will prove a use- 
ful resource for developers and provide 
new insights into the workings of the 
world's leading publishers. 



TRISTAN DONOVAN I Tristan is a U.K. -based freelance journalist. His work has 
appeared in The Guardian, Edge, and Games TM, among others. He is also a senior 
reporter for Young People Now. He can be reached via www.tdonovan.co.uk. 
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20. MIDWAY GAMES 

HEADQUARTERS: Chicago, IL 
FOUNDED: 1988 
CEO: David Zucker 

REVENUE (YE: 12/31/02): $ 190.4m (excludes coin-op games) 

EMPLOYEES: 345 developers 
WEB SITE: www.midway.com 
STUDIOS: U.S.A. (Chicago, IL; San Diego, CA) 

One of the grandfathers of gaming, Midway Games 
made its name in the arcades with a string of coin-op 
hits. However, in June 2001, Midway abandoned the declining 
arcade business to concentrate on developing games for the 
console and handheld markets. 

Revivals of back-catalogue games form a large part of 
Midway's output, although a third of its 2002 releases were 
original titles. External studios are responsible for half of 
Midway's output. Action and sports games form 95 percent of 
Midway's releases. 

During 2002 Midway published a number of ports based 
on its final batch of coin-op games. As time rolls on, this side 
of their publishing activities is also bound to disappear. 
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TOP 5 PUBLISHERS BY 1 
OVERALL DEVELOPER RATING* 


1 . Atari 


10/10 


2. Activision 


9.67/10 


3. Take -Two 


9/10 


4. Ubi Soft 


8.25/10 


5. Capcom 


7/10 


5. Electronic Arts 


7/10 


5. Sony 


7/10 


5. THQ 


7/10 



*Among available data 

19. EIDOS INTERACTIVE 

HEADQUARTERS: London, U.K. 
FOUNDED: 1990 
CEO: Michael McGarvey 

REVENUE (4/1/01 TO 6/30/02): $197.4m 

EMPLOYEES: 200 developers 

web site: www.eidos.com 

OTHER LABELS: Fresh Games, Proein 

STUDIOS: U.K. (Core Design - Derby; London), 

U.S.A. (Crystal Dynamics - Palo Alto, CA; 

Ion Storm - Austin, TX) 

Boosted by a one-off 15-month accounting period, 
Eidos, the British publisher best known for Tomb 
Raider, just manages to nudge ahead of Midway in our Top 

20. However, it's doubtful it would have done so in a nor- 
mal 12-month accounting year. 

Despite having had a bumpy ride on the stock markets 
since its Lara-fuelled heights, Eidos is one of the Top 20's 
biggest investors in original games, with just over half its 
releases being new IPs (second only to Microsoft). In com- 
parison, licensed games make up a mere 5 percent of the 
firm's output. 

Around 60 percent of Eidos's games are externally devel- 
oped. The remainder originates from the publisher's four inter- 
nal teams, three of which have retained their pre-Eidos identi- 
ty and are semi-autonomous. 

Although Eidos began life devising video compression soft- 
ware before entering game publishing in 1995, it is now purely 
a game company. The firm also operates the Fresh Games 
label (dedicated to releasing Japan-centric titles in the West) 
and owns 75 percent of Spanish game publisher Proein. 



18. KOEI 

HEADQUARTERS: Yokohama, Japan 
FOUNDED: 1978 
CEO: Keiko Erikawa 

REVENUE (YE: 3/31/03): $224.1m (estimated games only) 

EMPLOYEES: 447 

web site: www.koei.co.jp 

OTHER LABELS: ErgOSOft 

STUDIOS: Canada (Toronto), China (Beijing; Tienjing), 
Japan (Yokohama), Singapore 

It may lack the profile and output of its Top 20 peers, but 
Japanese publisher Koei has still managed to push its 
way into our ranking on the back of a handful of what many 
would label as niche titles. 

The firm's success is largely due to its range of strategy 
games (mostly based on Chinese and Japanese history) and 
its horse-racing series, Winning Post. Strategy games account- 
ed for half of the eight titles it launched last year (the lowest 
amount for any Top 20 publisher). 

Koei started life in 1978 as a producer of business soft- 
ware before entering game publishing in 1981. The business 
software division (Ergosoft) still exists but now makes up a 
tiny proportion of the company's activities. In addition to its 
game publishing and distribution operations, Koei has a 
media division producing strategy guides and audio-CD spin- 
offs from its games. 

Traditionally the firm's success was limited mainly to 
Japan, but in recent years Koei has attempted to broaden its 
horizons, expanding its overseas operations and the scope of 
its output with titles such as the rhythm-action game Gitaroo- 
Man. Despite such changes, Koei remains the only Top 20 
publisher that develops all its games in-house. 

Our estimated revenue is for all of Koei's divisions except 
for Ergosoft. 




17. ACCLAIM 

HEADQUARTERS: Glen Cove, NY 
FOUNDED: 1987 
CEO: Rodney Cousens 

REVENUE (YE: 8/31/02): $268.7m 

EMPLOYEES: 512 

web SITE: www.acclaim.com 

OTHER LABELS: Acclaim Max Sports, Acclaim Sports, 

AKA Acclaim 
STUDIOS: U.K. (Cheltenham; Manchester); 

U.S.A. (Austin, TX; Cincinnati, OH; Glen Cove, NY) 

With a hefty bout of cost-cutting currently in 
progress, Acclaim is having a rough time with share 
price tumbles and board-level changes to boot. The firm, a 
publisher of console and handheld games, relies on its range 
of sports titles for most of its income, and these comprise 
65 percent of Acclaim's roster, the highest percentage of any 
Top 20 publisher. Sequels are also a fundamental part of 
Acclaim's offerings, accounting for 74 percent of releases. 

External studios develop in excess of 65 percent of 
Acclaim's products, and with plans to cut back internal staff 
there is a possibility that this figure could rise. But external 
studios seem rather less than impressed by their experiences 
with Acclaim, with producer quality and milestone payment 
efficiency scoring a poor 2 out of 10 in our developer survey. 
The survey also found that Acclaim takes a hands-on role in 
the development process, scoring 7 out of 10 on this front. 

Acclaim publishes its games under several sub-labels, 
including Acclaim Sports, Acclaim Max Sports, and AKA 
Acclaim. Acclaim Publishing produces strategy guides for both 
Acclaim and other publishers' games. 



16. NAMCO 

HEADQUARTERS: Tokyo, Japan 
FOUNDED: 1955 
CEO: Kyushiro Takagi 

REVENUE (YE: 3/31/03): $359. 7m (home games only) 

EMPLOYEES: 2,225 

WEB SITE: www.namco.com 

STUDIOS: Japan (Monolith Soft - Tokyo; Tokyo) 

While amusement arcades continue to play a signifi- 
cant role in Namco's operations, home games are 
its most profitable division. Namco also views the division as 
having the greatest room for growth out of all its businesses 
and as such is working to increase its publishing activities. 

Licenses make up less than 5 percent of Namco's output, 
but games based around existing IPs account for 68 percent 
(down from a massive 87.5 percent reliance the year before). 

The firm publishes console and handheld titles only. 
Externally developed games made up fewer than 4 percent of 
Namco's releases last year, although the levels have been 
higher in previous years. 

Beyond home videogames, Namco produces coin-op 
games and runs amusement arcades and parks. Further busi- 
ness interests include hotels, movie special effects, music 
web sites, and the Italian Tomato restaurant chain in Japan. 
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TOP 5 PUBLISHERS BY 
PERCENTAGE ORIGINAL TITLES 


1. Microsoft 


57.7% 


2. Eidos 


52.6% 


3. Sony 


45.5% 


k. Take-Two 


40.9% 


5. Koei 


37.5% 



15. BAN DAI 

HEADQUARTERS: Tokyo, Japan 
FOUNDED: 1950 
CEO: Takeo Takasa 

REVENUE (YE: 3/31/03): $372. 6m (forecast games only) 
EMPLOYEES: 844 
web SITE: www.bandai.co.jp 
other labels: Banpresto 
STUDIOS: Japan (Banpresoft - Tokyo; 
Bee - Tokyo; Tokyo) 

The game arm of the Japanese toy and media giant 
Bandai has established a name for itself in game pub- 
lishing, despite failing to loosen Nintendo's grip on the hand- 
held market with its Wonderswan line of handhelds. 

While still supportive of the Wonderswan consoles, the 
game-publishing wing is mainly focused on producing titles 
for the Playstation and Playstation 2. Most of the firm's 
releases are based on Bandai properties or other well-known 
franchises, which make up nearly 61 percent of the firm's 
games. External teams were responsible for just over a quar- 
ter of its games. 

Bandai as a whole is involved in a huge range of markets, 
from car parts and coin-op machines to toys and TV cartoons. 
As a breakdown of earnings from its home games division was 
not available at the time of going to press, the revenue figure 
given here is Bandai's own forecast for the division's earnings. 



www.gdmag.com 
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TOP 20 PUBLISHERS 
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Revenue 
($millions) 
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An e denotes our estimated figures for their games division. 
An f denotes a figure forecast by the publisher itself. 
External teams - The percentage of releases developed externally. 
Internal size - Number of development staff. 

Producer Score - Average rating (out of 10) given by external studios of the publisher's 

producers. A 10 score is the best. 
Milestone Score - Average rating (out of 10) given by external studios of the promptness 

of the publisher's milestone payments. A 10 score is the most prompt. 
Marketing Score - Average rating (out of 10) given by external studios of the publisher's 

marketing efforts. A 10 score is the best. 



Involvement Score - Average rating (out of 10) given by external studios on the level of publisher 
involvement in external projects. A 10 score means heavily involved, 1 is completely hands-off. 

Overall Score - Average rating (out of 10) given by external studios on their overall experience 
of working with the publisher. 

Main Format - The format the publisher releases the most games on. 

RPG/Sports & Racing/ Action/Simulation/Strategy - Percentage of titles that fall into 
these categories. 

Puzzle & Misc. - Titles that do not fit the above definitions. 

Children's - Games aimed purely at the children's market. 

Consoles/Handhelds/Computers - Percentage of releases by a publisher for a particular 
type of system. 



14. CAPCOM 

headquarters: Osaka, Japan 
FOUNDED: 1979 
CEO: Kenzo Tsujimoto 

REVENUE (YE: 3/31/03): $407.3m (excl. arcade divisions) 

EMPLOYEES: 800 developers 
web SITE: www.capcom.com 
STUDIOS: Japan (Osaka); South Korea (Seoul); 
U.S.A. (Sunnyvale, CA) 

Despite the underperformance of several of its big titles 
last year, Capcom remains a major force in game pub- 
lishing. The firm relies heavily on sequels, with 69 percent of 
its titles being based on existing IP, notably Resident Evil. 
Licensed IP plays a much smaller role, accounting for 25 per- 
cent of its games, while original games make up just 19 per- 
cent of releases. 

Action titles dominate the Capcom range, with 69 percent 
of its games falling into this category, the highest percentage 
for any publisher in the Top 20. Just short of 24 percent of 
Capcom games are developed externally. Capcom also plays 
external developer on occasion, notably creating Game Boy 
Color incarnations of Zelda for Nintendo. 

Capcom still maintains a presence in the arcade industry, 
although the sector's long-term decline makes it an increasing- 
ly less important part of the business. The firm's Japanese arm 
also dabbled in board games last year with some success. 



13. THQ 

HEADQUARTERS: Calabasas Hills, CA 
FOUNDED: 1989 
CEO: Brian Farrell 

REVENUE (YE: 12/31/02): $480.5m 

EMPLOYEES: 714 

WEB SITE: www.thq.com 

OTHER LABELS: THQ Wireless, ValuSoft 
STUDIOS: U.K. (Woking); U.S.A. (Calabasas 
Hills, CA; Cranky Pants - Kirkland, WA; Genetic 
Anomalies - Cambridge, MA; Grass Valley, CA; 
Heavy Iron - Culver City, CA; Helixe - Lexington, 
MA; Outrage Games - Ann Arbor, Ml; Pacific 
Coast P&L - Santa Clara, CA; Rainbow Studios - 
Phoenix, AZ; ValuSoft - Waconia, MN; Volition - 
Champaign, IL) 

Although a significant chunk of its games are pitched at 
the children's and budget markets, THQ has built itself 
into one of the world's biggest publishers. 

Around 62 percent of THQ's titles are developed external- 
ly, although it has, primarily through acquisitions, created a 
robust internal development function comprising 11 U.S. stu- 
dios and one U.K. studio. 

THQ's releases tend to be based on licenses (60 percent), 
many of which are based on children's cartoon characters 
from Nickelodeon. Original products account for a quarter of 
the firm's output. 

Alongside its clutch of studios, THQ also owns budget 
game publisher ValuSoft and has created THQ Wireless, a divi- 
sion dedicated to mobile gaming. 



12. UBI SOFT 

HEADQUARTERS: Paris, France 
FOUNDED: 1986 
CEO: Yves Guillemot 

REVENUE (YE: 3/31/03): $493.8m 

EMPLOYEES: 1,260 developers 

web site: www.ubi.corn 

OTHER LABELS: Blue Byte, Red Storm, SSI 

STUDIOS: Australia (Sydney); Canada (Montreal); 

China (Shanghai); Denmark (Copenhagen); 

France (Paris); Germany (Blue Byte - Mulheim; 

Diisseldorf); Italy (Milan); Japan (Tokyo); 

Morocco (Casablanca); Romania (Bucharest); 

Spain (Barcelona); U.K. (Oxford); U.S.A. (Red 

Storm - Morrisville, NC) 

When it comes to internal development, few publish- 
ers can boast such a worldly presence as Ubi Soft, 
which seems to have a team in every corner of the globe. 

Despite such a large internal development function the 
firm still uses external studios for more than 48 percent of its 
releases. Studios who have worked with Ubi Soft are positive 
about the experience, giving producer quality and milestone 
payments respective ratings of 7.5 and 10 out of 10. Ubi Soft 
also takes a backseat in the development process, with 
developers rating the publisher's level of involvement as 3.75 
out of 10. Just under a fifth of Ubi Soft's games are original 
releases and 45 percent are based on licenses. Nearly 48 
percent of titles are sequels to previous games. 

The firm is purely a game publisher and owns a number of 
sub-labels via acquisitions, namely Blue Byte, Red Storm, and 
SSI (which is active as a label but not as a studio). 
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11. SQUARE ENIX 

HEADQUARTERS: Tokyo, Japan 
FOUNDED: 2003 
CEO: Yoichi Wada 

REVENUE (YE: 3/31/03): $526.6m (estimate) 

EMPLOYEES: 1,097 developers 
WEB SITE: www.square-enix-usa.com 
STUDIOS: Osaka (Japan), Tokyo (Japan) 

Square Enix was created on April 1, 2003, by the merger 
of Japanese publishers Enix, founded in 1975, and 
Square, formed in 1986. The result is a new publishing super- 
power within spitting distance of the Top 10. 

Square's Final Fantasy and Enix's Dragon Quest games were 
the flagship products of the firms when they were separate, 
and the importance of role-playing titles for Square Enix is 
undeniable. In total, RPGs made up 48 percent of the firm's 
releases. In comparison, action titles do not feature in the 
firm's lineup at all. 

The publisher's Japan-based internal teams provide the 
majority of games for the company, with the remaining 24 per- 
cent of releases being produced by external Japanese studios. 

The reliance on the Dragon Quest and Final Fantasy series 
means that more than 50 percent of Square Enix's releases 
are sequels or spin-offs, although a healthy 36 percent of 
titles are original games. 

Game merchandising is the only activity beyond game 
development in which Square Enix is involved. Our estimated 
revenue combines the last results posted (both for the year 
ended March 31, 2003) by Square and Enix when they were 
separate businesses. 
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10. SEGA 

HEADQUARTERS: Tokyo, Japan 
FOUNDED: 1952 (as Service Games) 
PRESIDENT: Hideki Sato 

REVENUE (YE: 3/31/03): $563.6m (home games software only) 

EMPLOYEES: 1,100 

web site: www.sega.com 

OTHER LABELS: Sega Mobile, Sega Sports 

STUDIOS: Japan (Amusement Vision, Hitmaker, 
Overworks, Sega AM-2, Smilebit, Sonicteam, 
United Game Artists, Wave Master, Wow 
Entertainment - all Tokyo); U.S.A. (Visual 
Concepts - San Rafael, CA) 

The messy aftermath of the Dreamcast continues to 
haunt Sega despite the console's discontinuation in 
2001. Sega's hopes of becoming the premier third-party pub- 
lisher have yet to be realized, and the procession of on-off 
merger partners and buyers that Sega has entertained in the 
past year has done little to help. 

The changes are set to continue in the coming months as 
Sega sets about overhauling its internal development studios. 
Although details were thin on the ground as the Top 20 went 
to press, Sega intends to shut down four studios and create 
two new ones. 

Sega's various internal studios handle 72 percent of the 
firm's games. Although internal teams dominate the release 
schedule, Sega bucks the trend among Japanese publishers 
of primarily using Japanese studios, hiring North American 
and European developers regularly. 

Sequels dominate Sega's releases (75.5 percent), although 
licenses only form 18 percent of its products (equal to the 
amount of original products). Sports and racing games play a 
major role in Sega's business, taking up 49 percent of its output. 

As well as its Sega Sports label, the firm has also creat- 
ed a mobile games division, Sega Mobile. Outside the con- 
sumer game market, Sega continues to be a major force in 
the arcade business, both as a coin-op manufacturer and 
operator of arcades. More recently, some of the firm's inter- 
nal studios have also begun developing games for other 
publishers, notably Nintendo. 



9. MICROSOFT GAME STUDIOS 

HEADQUARTERS: Redmond, WA 
FOUNDED: 1975 

VP GAMES PUBLISHING: Ed Fries 

REVENUE (YE: 6/30/02): $614.4m (est. game-only revenue) 

EMPLOYEES: 800 developers 
WEB SITE: www.microsoft.com 
STUDIOS: U.K. (Rare - Tywcross); U.S.A. 
(Ensemble - Dallas, TX; Redmond, WA) 

Pinning down the size of Microsoft's game-publishing 
arm is not an easy task. Before Xbox was put in the 
newly created Home and Entertainment division, the company 
combined figures for Xbox hardware sales with games sales 
and also included revenues from the MSN network. 

As a result we've estimated not only how much of the fig- 
ure came from MSN but also how much came from Xbox hard- 
ware sales. However, we've been unable to take account of the 
effect of Xbox accessory sales and royalties from third-party 
games, so these may be included in our estimate. 

Microsoft Game Studios publishes both PC and Xbox 
titles. The launch of the Xbox altered Microsoft's game-pub- 
lishing approach significantly, and 55 percent of its output is 
now for the console, despite the Xbox launch occurring part- 
way through the accounting period in question. 

Nearly 58 percent of Microsoft's titles are original games, 
the highest amount of any Top 20 publisher, although this 
might be due to its desire to build up a range of exclusive IPs 
for the Xbox. Licenses and sequels were poor relations, clock- 
ing up 23 and 31 percent of Microsoft's games, respectively. 
Thanks to the Microsoft Train Simulator and Microsoft Flight 
Simulator range on PC, Microsoft is the biggest publisher of 
simulations in the Top 20. 

While the purchase of Ensemble Studios and Rare has 
bolstered Microsoft's internal development power, about 64 
percent of Microsoft's games are by external studios. 

For external studios, Microsoft is nothing if not a reliable 
paymaster, scoring a perfect 10 when it comes to paying mile- 
stones on-time. But in other areas it does less well, with a 6 
for producer quality and its marketing efforts. 



www.gdmag.com 
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8. KONAMI 

HEADQUARTERS: Tokyo, Japan 
FOUNDED: 1969 
CEO: Kagenasa Kozuki 

REVENUE (YE: 3/31/03): $740.2m 
EMPLOYEES: 4,313 
WEB SITE: www.konami.com 
STUDIOS: Japan (Tokyo, Osaka); U.S.A. (Hawaii; 
Redwood City, CA) 

When it comes to the sheer number of titles, Konami 
wins hands-down. The firm published 64 titles in its 
last accounting year, six more than its nearest rival, Atari. 

This prolific output is achieved almost entirely by 
Konami's own development studios or by semi-independent 
studios such as Mobile 21 (50 percent owned by Konami; 
Nintendo owns the other half). The result is that independent 
studios produce just 7 percent of Konami's titles. 

Konami's output covers a good spread of genres, although 
its wide range of sports and racing titles are the largest slice 
(33 percent). Konami publishes titles for all the leading plat- 
forms, although home console games form the bulk of its releas- 
es (67 percent) followed by handheld consoles (25 percent). 

Sequels accounted for 78 percent of Konami's games last 
year, the highest level for any Top 20 publisher. Original 
games made up 22 percent of releases. 

Konami also has business interests in coin-op games, 
toys, and card games (notably Yu-Gi-Oh!). It also runs a chain 
of health and fitness clubs in Japan. 



7. ATARI 

HEADQUARTERS: Lyon, France 
FOUNDED: 1983 
CEO: Bruno Bonnell 

REVENUE (YE: 6/30/02): $761.9m 

EMPLOYEES: 1,981 

web site: www.atari.com 

STUDIOS: Australia (Melbourne House - Melbourne); 
Canada (Montreal); France (Eden Studios - 
Lyon); U.K. (London; Reflections - Newcastle- 
upon-Tyne); U.S.A. (Shiny - Aliso Viejo, CA; 
Beverly, MA; Humongous - Bothell, WA; Paradigm 
- Carrollton, TX; Legend - Chantilly, VA; Hunt 
Valley, MD; Plymouth, MINI; Santa Monica, CA) 

Built on the back of a complex and lengthy series of 
acquisitions, the publisher formerly known as 
Infogrames has established itself as one of the industry's 
biggest players. In recent years the company has undergone 
a barrage of buy-outs, studio closures (most recently one in 
Sheffield, U.K.), and a rebranding exercise to become Atari. 

Despite Atari's hefty collection of studios, 74 percent of its 
games are still developed externally. Releases are biased 
toward PC games, which account for 46 percent of titles pub- 
lished, primarily due to Atari's strong edutainment arm. 

Original games make up around 22 percent of Atari's 
releases, while games based on licenses make up a further 
54 percent. 

When it comes to relations with external studios, Atari is 
viewed as one of the best, with developers rating the publish- 
er a full 10 out of 10 for producer quality and milestone pay- 
ment efficiency. 



6. TAKE-TWO 

HEADQUARTERS: New York, NY 
FOUNDED: 1993 
CEO: Jeffrey Lapin 

REVENUE (YE: 10/31/02): $794.0m 

EMPLOYEES: 939 (last reported) 
WEB SITE: www.take2games.com 
OTHER LABELS: Gathering, Global Star, 

Gotham Games, Rockstar, Talonsoft 
STUDIOS: Austria (Rockstar Vienna); 

Canada (Global Star - Mississauga, ON; 

Rockstar Vancouver); UK (Rockstar North - 

Edinburgh); U.S.A. (Gathering - Austin, TX; 

Talonsoft - Baltimore, MD; Pop Top - Fenton, 

MO; Rockstar San Diego) 

Propelled by the huge success of the Grand Thef Auto 
series, Take-Two have quickly climbed to the upper 
reaches of the Top 20 with annual revenues almost doubling 
in the wake of Grand Theft Auto 3. 

But while a hefty chunk of Take-Two's income may result 
from the internally developed Grand Theft Auto games, external 
studios do feature heavily in the firm's activities. In its fiscal 
2002, just short of 83 percent of its games were developed 
externally, the biggest share of any Top 20 publisher. 

Take-Two concentrates on action and sports games, which 
together account for 86 percent of the publisher's releases. 
The firm concentrates on console and PC titles, with handheld 
releases being few and far between. 

Roughly half of Take-Two's products are sequels, with origi- 
nal games accounting for a further 41 percent of releases. 
Licenses make up just 10 percent of releases. 

Take-Two's reputation with external studios is sterling, and 
its producers scored an average rating of 10 out of 10, the 
highest of any Top 20 publisher. Milestone payment efficiency 
was highly rated at 8. Take-Two's involvement in the creative 
process was seen as relatively light, scoring a 3 out of 10. 

There is a high degree of overlap between Take-Two's five 
labels, but generally speaking Gathering concentrates on PC 
titles, Global Star publishes budget PC games and PDA titles, 
Gotham Games publishes titles aimed at all ages, while 
Rockstar Games aims at older players. Finally, TalonSoft pub- 
lishes PC strategy, simulation, and action games. 

The company also owns Global ProBiz, a spinoff from 
Global Star that publishes business utility software, and 
peripheral manufacturer Joytech. 



r TOP 5 USERS OF ^ 
EXTERNAL STUDIOS 
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TOP 5 PUBLISHERS OF 
CHILDREN'S GAMES 



1. Vivendi Universal 42.6% 

2. THQ 40.4% 

3. Atari 22.4% 

4. Electronic Arts 13.9% 

5. Ubi Soft 13.6% 



5. VIVENDI UNIVERSAL GAMES 

HEADQUARTERS: New York, NY 

FOUNDED: Became Vivendi Universal in 2000 

although the business dates back to the 1980s 
CEO: Ken Cron 

REVENUE (YE: 12/31/02): $832.5m 

EMPLOYEES: 2,000 

WEB SITE: www.vugames.com 

LABELS: Black Label Games, Blizzard, Fox Interactive, 
KnowledgeAdventure, NDA Productions, Sierra, 
Universal Interactive 

STUDIOS: France (Coktel - Paris); Sweden 
(Massive Entertainment - Malmo); 
U.S.A. (Sierra - Bellevue, WA; Impressions - 
Cambridge, MA; Blizzard - Irvine, CA; Knowledge 
Adventure, Black Label Games, Universal 
Interactive - Los Angeles, CA; Blizzard North - 
San Mateo, CA; Papyrus - Watertown, MA) 

Up for sale it may be, but the troubles of its parent com- 
pany don't distract from the powerful position Vivendi 
Universal Games has in the publishing market. 

A large part of the publisher's success is due to its 
strength in the edutainment sector, where it bears the 
KnowledgeAdventure label. Around 43 percent ofVivendi's 
titles are aimed at the children's market, the highest amount 
of any Top 20 publisher. As a result, computers (PC and 
Macintosh) are the platforms of choice at Vivendi, forming 61 
percent of all releases. Consoles represent just 25 percent, 
the smallest for any Top 20 publisher. 

Original games make up little of the publisher's releases 
(11 percent, to be precise, the lowest of any Top 20 publisher), 
the focus being firmly on licenses and sequels. 

Approximately half ofVivendi's games are made externally, 
although relations with studios are patchy. The firm's produc- 
ers score a healthy 8 out of 10, but its performance on mile- 
stone payments and marketing efforts is much weaker, 
respectively scoring 4 and 2. In fact, as a whole, external 
teams give Vivendi an overall score of only 3 out of 10. 



TOP 5 PUBLISHERS BY 
NUMBER OF TITLES 



1. Konami 

2. Atari 

3. Vivendi Universal 

4. Sega 

5. Capcom 
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4. ACTIVISION 

HEADQUARTERS: Santa Monica, CA 
FOUNDED: 1979 
CEO: Robert Kotick 

REVENUE (YE: 3/31/03): $864.1m 

EMPLOYEES: 612 

web SITE: www.activision.com 

OTHER LABELS: Activision 02, Activision Value 

STUDIOS: U.K. (Slough); U.S.A (Gray Matter - 

Los Angeles, CA; Z-Axis - Hayward, CA; 

Luxoflux - Santa Monica, CA; Neversoft - 

Woodland Hills, CA; Raven - Madison, Wl; 

Shaba Games - San Francisco, CA; Treyarch - 

Santa Monica, CA) 

Since its formation by a bunch of rebel Atari programmers 
in 1979, Activision has been one of the top dogs in the 
industry (a brush with death in the early 1990s notwithstand- 
ing). Today much of Activision's success is due to the licensed 
games that account for 64 percent of its releases, the highest 
of any Top 20 publisher. In comparison, original products make 
up little of the publisher's output, forming a paltry 14 percent. 

In terms of development Activision is a big user of external 
studios (71 percent of its releases). Home console games are 
the largest segment of Activision's products, accounting for 69 
percent of its releases. Handhelds come next with a 22 per- 
cent share, while computer titles form just 9 percent. 

External studios report good relations with Activision, and 
its milestone payment record is a perfect 10 out of 10. 
Producer quality is good, with an 8.7 rating, and its overall 
mark from developers is an impressive 9.7 out of 10. 

Activision is solely involved in game publishing. Its 
Activision 02 label handles its alternative sports releases. 
Activision Value is its budget brand. 




3. NINTENDO 

HEADQUARTERS: Kyoto, Japan 
FOUNDED: 1933 (as Yamauchi Nintendo & Co., 
although its origins date back to the late 19th cen- 
tury) - entered coin-op game industry in 1963. 
CEO: Satoru Iwata 

REVENUE (YE: 3/31/03): $2, 128.5m (game sales only) 

EMPLOYEES: 1,000 

WEB SITE: www.nintendo.com 

STUDIOS: Canada (Silicon Knights - Toronto); Japan 

(Intelligent Systems - Kyoto; Saru Brunei - Kyoto; 

Kyoto; Brownie Brown - Tokyo; NDCube - Tokyo); 

U.S.A. (Retro Studios - Austin, TX) 

The Top 20's oldest company with roots dating back to the 
late 19th century, Nintendo proper first appeared in 1933 
with the formation of Yamauchi Nintendo & Co. In 1963 the 
firm became Nintendo and entered the coin-op game industry. 

Nintendo's products cut across all genres, and while it's 
reliant on the sequels and spin-offs of its big-name titles 
(these form 64 percent of its releases), some 36 percent of its 
output is original products. In contrast, licenses barely register, 
accounting for a mere 3.5 percent of Nintendo's titles. 

Around 46 percent of Nintendo games are developed 
externally, but the firm tends to limit its use of outside studios 
to a select few. This external studio pool mainly consists of 
Japanese teams, although western teams have been getting 
more of a look-in recently. Nintendo also tends to part-own a 
significant number of the external studios with which it works. 



2. SONY COMPUTER 
ENTERTAINMENT 

HEADQUARTERS: Tokyo, Japan 
FOUNDED: 1993 
CEO: Ken Kutaragi 

REVENUE (YE: 3/31/03): $2,180.5m (estimate) 

EMPLOYEES: 1,800 

LABELS: SCEI, SCEA, SCEE 

web SITE: http://global.scei.co.jp 

STUDIOS: Japan (Contrail - Tokyo; Polyphony 

Digital - Tokyo; Zener Works - Tokyo; Tokyo); 

U.K. (Cambridge; Liverpool; London); U.S.A. 

(989 Sports/Studios - San Diego; Bend, OR; 

Foster City, CA; Salt Lake City, UT; Naughty 

Dog - Santa Monica, CA) 

With 12 internal studios and a hefty 44 titles pub- 
lished in its last accounting year, it should come as 
little surprise that Sony Computer Entertainment is wedged 
firmly in the upper reaches of the Top 20. 

We estimate Sony's revenues for game publishing (includ- 
ing income from third-party publisher royalties) stands at 
nearly $2.2 billion, using installed base figures for Playstation 
and Playstation 2 consoles in the year ended March 31, 
2003, as the basis. 

Sony's publishing output touches most genres but action 
and sports/racing games dominate, making up 32 and 22 
percent of its output, respectively. Like Microsoft, Sony invests 
heavily in new IP (no doubt to bolster the number of exclusive 
Playstation games on the market), and in its last accounting 
period 45 percent of its games were original. Sequels also 
account for 45 percent of titles, while licensed products make 
up just 18 percent. 

While Sony boasts sizeable internal development, it stills 
turns to external studios for 45 percent of its releases. 
External developers report mixed experiences with Sony, its 
producers score just 5.5 out of 10, while its milestone pay- 
ments score 8 out of 10. 

Structurally, Sony Computer Entertainment consists of 
three divisions: SCEI (Japan and Asia), SCEA (America), and 
SCEE (Europe and Australia). Each division controls what it 
does and does not publish. A separate company, Sony 
Online Entertainment, handles Sony's online PC game titles 
such as Everquest. 

The forthcoming PSP handheld will doubtless make a big 
impact on Sony Computer Entertainment's future output. 



1. ELECTRONIC ARTS 

HEADQUARTERS: Redwood City, CA 
FOUNDED: 1982 
CEO: Lawrence Probst 

REVENUE (YE: 3/31/03): $2,482.2m 
EMPLOYEES: 4,000 
web SITE: www.ea.com 
LABELS: EA Games, EA Sports, EA Sports Big, 
Pogo.com 

STUDIOS: Australia (Melbourne); Canada 
(Vancouver); Japan (Tokyo); U.K. (Chertsey; 
Warrington); U.S.A. (Irvine, CA; Los Angeles, CA; 
Maitland, FL; Maxis - Walnut Creek, CA; Origin 
Systems - Austin, TX; Tiburon - Orlando, FL; 
Redwood City, CA; San Francisco, CA) 

Was it only 20 years ago when EA was churning out 
their "We See Farther" ads? Having long eclipsed 
its rival third-party publishers (its revenues are almost three 
times that of Activision, the next biggest third-party publisher), 
EA now even overshadows Nintendo's and Sony's publishing 
operations. 

In addition to having the biggest revenue, EA also lays 
claim to having the most releases (103 were published in 
its last financial year). Most of these are now handled by 
the firm's range of internal development studios, leaving 
external developers to produce 40 percent of EA's output. 

Despite the internal studios' overshadowing external 
studios, relations with outside developers are good, with 
milestone payments and producer quality both rated 8 out 
of 10 by developers with experience in dealing with the 
publisher. 

Licenses and sequels are a core element of EA's output. 
Licenses account for 51 percent of its games, while 60 per- 
cent are sequels, spin-offs, or expansion packs. Original 
games make up a relatively low 16 percent. 

Sports and racing games are EA's bread-and-butter gen- 
res, taking up 46.5 percent of its release schedule. EA con- 
centrates on console releases primarily (64 percent of all 
titles), followed by PC titles (25 percent). 

EA Games handles non-sports titles, while EA Sports and 
EA Sports Big handle sports output (the latter concentrates 
on arcade and alternative sports while the former leans 
toward simulation). The advertising-funded Pogo.com provides 
free online card, board, and puzzle titles. # 



METHODOLOGY 



Publishers have been ranked by revenue from home game sales using figures from the last year-end accounts 
before April 1, 2003. Revenues that were not originally in U.S. dollars were converted using historical 
exchange rate data from the Federal Reserve. In some cases where publishers didn't make game-only income 
available, such revenue was estimated, and these instances are clearly indicated in the text. 

When analyzing the games a publisher has released, the games examined were those published in the 
period the publisher's revenue figure covers. This data, along with most general company information, came from 
the publisher itself, however in several cases it was necessary to compile such information independently. Budget 
re-releases, compilations, and repackaged games have not been included. Mobile phone, coin-op, and interactive 
TV games have also been excluded. 

The developer ratings are the sum rankings given anonymously by developers who have worked with the publisher. 
In the text we have defined the following terms as follows: A "release" is a game for a particular format (so if a 
game appears on four formats it counts as four releases), whereas a "game" counts as a "title" regardless of how 
many formats it appears on (so a multi-format game counts as one title). A "sequel" is any game that uses an 
existing videogame IP. A "license" is any game that uses a non-videogame IP as its basis (including IPs owned by 
the publisher's parent company). An "internal studio" is one that is more than 50 percent owned by a publisher. 

Every effort has been made to ensure the accuracy of the information contain within this article. However, we 
cannot guarantee its accuracy or completeness, and we will not accept liability for any direct, indirect, or conse- 
quential loss arising from its use. 
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Gathering Assets on Loc 
Without Getting Crushed 






Enter the Matrix is a lot of things: an exciting 
project, a lucrative licensing opportunity, a 
new type of film-game production scenario. 
Through my professional lens, though, the 
project was a unique learning experience, 
another chapter in the big book of game 

producer know-how; 



Larry and Andy Wachowski, the filmmakers and creators 
of The Matrix film trilogy, envisioned the game project as 
being truly complementary to the films. Enter the Matrix 
wasn't simply a lunchbox tie-in deal — the game was 
placed right alongside the film production itself, with a 
level of collaboration previously unknown in either Hollywood or the 
gaming industry. 

The arrangement required Shiny's team to rethink many issues, 
chief among them the fundamental need to gather crucial assets, digi- 
tal and otherwise, in the midst of a whirlwind of a film production. All 
told, Shiny team members spent roughly 25 weeks on-location with the 
film production, gathering source material for the game. 

The Wachowskis blazed a trail for how games can complement 
films, and this style of collaboration will, we hope, become the rule 
rather than the exception. More and more game developers will find 
themselves on film sets and at studios with three goals in mind: gath- 
ering the kinds of creative assets that will make a great game, keeping 



a lid on their budget, and doing it all while managing and preserving 
the all-important relationship with the film production. 

With Shiny's lessons learned, there are several high-level points to 
share about entering the film world and bringing back the kinds of 
assets that will allow a game developer to create the best possible 
project with the least number of headaches. 

Asset Acquisition and Control 

Gathering and managing assets sounds like a producer's job, and it 
usually is, but understanding the process is useful for anyone in 
game development. 

Know what you need and when you can get it. The first rule of 
gathering assets from a license holder, such as during a movie produc- 
tion, is that you can never go back and get more material. On location at 
the Matrix sequels, sets were constructed and demolished with lightning 
speed. Actors shot their scenes and left the production just as quickly. 
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| enough to capitalize on them due to collaboration in scheduling. You'd 

think that witfr-a total film production time of well over a year there 
would be plenty of time to gather assets. On the contrary, larger prod' 
^^ions mean smaller windows of opportunity. Grab the assets while yoiS!^ 
^r-^S^can. because once the set is torn down and the actors go home, they're 
gone for good. 

The second rule is that you must fully understand the scope of the 
game project and all of its needs. This may sound obvious, but in truth 
many developers don't do this early enough in production. In any 
license relationship, the licensor is not going to just offer you everything 
they have. You must first outline everything needed for the game and 

— "jr 

then ask for the right materials. The first step for asset gathering, then, 
is getting a complete understanding of the game's vision, with input 
from the designers, department leads, and individual team members. 




mentiTying your asset neeas is important, ana so is taiKing to tne people 
who will actually be working with the assets. The wrong angle on a digi- 
tal picture can lead to hassles later. Don't waste time fixing something 
in Photoshop when you can capture it correctly the first time out. 
Know what you don't need. On the other hand, you can't take the 
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you might possibly need means you'll end up with an unwieldy amount 
of data, only some of which is useful. We snapped more than 25,000 
digital photographs for Enter the Matrix — in hindsight, a little exces- 
sive. Not only did we need additional network storage space, we wasted 
time making artists sift through thousands of images to find the gems 
they actually needed. 

A second problem with going after everything you can get your hands 
on is that it simply takes too much time. In many cases, getting digital 
photos of the sets meant that set demolition plans were delayed. Motion 
capture work meant tying up an actor's time for a day, but some moves 
turned out to be unnecessary. The latter point is especially key because 
in some cases, the game publisher may bear the daily shooting costs of 
an actor working for the developer. 

You'll need to work closely with the licensor's interactive department 
or production department. Not only will you have the best chance of 
being in the right place at the right time, but it also means significant 
cost savings. For Enter the Matrix, motion capture shoots were sched- 
uled alongside mocap shoots for the film, meaning the visual effects 
department and the game shared costs for stage construction, talent, 
striking the stage, and the like. Planning your needs on the game side 
is only half the battle — planning the methods of asset gathering with 
your licensor is a crucial cost-saving step. 

STUART ROCH I Stuart is the executive producer at Shiny 
Entertainment and has seen The Matrix enough times to get free 
passes to any show ending in "-Con." He can be contacted at 
sroch@shiny.com. 



Plan storage and access. Finally, you'll need erjD.lan for asset con- 
trol. Once you gather all these assets, where will they be stored? Who 
will have access to them? In the case of the Matrix production, secrecy 
and data security were extremely important: We had to strike a balance 
— providing access on a need-to-use basis without hampering some- 
one's ability to do his job. A secure network location for all the data is 
the best bet, providing access rights to key team members as needed. 
Scan all hard-copy material and store the data in the same location as 
the digital assets. 

Whatever your plan, make sure you have one. Storing data in willy- 
nilly fashion — some in filing cabinets, some in binders, some on 
portable hard drives, some on the network — is a nightmare scenario. 
A central, organized data repository (with regular backups) could be 
the difference between an invaluable resource and a complete waste 
of time. 

Types of Assets to Gather 

hile the scope of your project will dictate the types of assets you 
should expect from your licensor, the list of assets you can 
hope to gather is surprisingly large. In the case of a film license, just 
about everything the audience sees is a valuable resource. 

The most obvious assets are digital reference photographs of sets, 
props, and costumes, plus ADR recording, cyber-scans, and motion 
capture of the talent. But there's much more beyond the obvious, if you 
know to ask for it. 
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In preproduction or planning stages, acquiring storyboards 
and conceptual artwork can get your team inspired and off in 
the right general direction. Ask for construction blueprints of 
sets, AutoCAD files of upcoming production pieces, and early 
versions of the scripts. 

Once you and your licensor are in full production, take some 
of the early assets you've already gathered and compare them to 
the final products. For example, compare costume sketches with 
fabric swatches for the production costumes. Set references can 
be contrasted with the final set of blueprints or lidar scans of the 
locations. This will also be the time you'll want to conduct any 
detailed photo sessions of sets of the actors, conduct motion 
capture if not already completed, and perform ADR sessions of 
any actors you'll need for the game. 

Digital Photography 

One of the most important types of assets you'll gather dur- 
ing the course of your project is digital reference photog- 
raphy. Digital pictures of sets, actors, props, vehicles, and other 
assets are one of the primary means for your artists to create 
game assets faithful to the source material. 

Do it yourself. The first step here is being firm with your 
licensor that one of your team members needs to take the pic- 
tures. The licensor may prefer to provide a photographer (and 
it may sound like a reasonable suggestion), but there are two 
key problems with this arrangement. 

First, while a third-party photographer may be an expert in 
photography, he or she is unlikely to understand fully the con- 
text in which the photographs will be used. Taking detailed 
reference photos for a game artist to work with is a completely 
different animal from taking general overview shots. The 
angle, lighting, context, and the shot selection itself can all 
mean the difference between something that's merely a good 
reference and something that's truly useful for an artist to 
implement in the game. 

Another problem with using a third-party photographer is 
that it robs you of the ability to answer questions about the 
subject matter later. On Enter the Matrix, there were count- 
less times when an artist had questions about light levels, col- 
ors, and subject matter. Fortunately, we had producers and 
artists on-hand who could answer those questions, as they had 
actually taken the shots themselves. 

Get ready for your close-ups. Don't neglect opportunities to 
capture the details of your shooting subject in addition to the 
overall shots. Overall set reference is useful, but your artists 
will also need shots of the little details, such as wall textures, 
close-ups of floor patterns, and subtle character nuances. 

On one occasion while working on Enter the Matrix, the 
film crew's first unit was resetting cameras for the next shot. 
At that point, the interactive producer said, "Go! Now's your 
chance to get what you need." While I felt silly taking close- 
up pictures of crates, piles of garbage, and rocks while the 
actors looked on, I couldn't give up the opportunity. Take 




Side-by-side comparison of Jada Pinkett-Smiths reference photo and 
her final in-game character Niobe. 



advantage of any opportunity you have to gather assets, and 
don't be afraid to do the job you need to do to support your 
team back home. By the end of shooting, everyone on the 
Matrix crew understood why we were taking close-ups of 
doorknobs, and I think they even came to respect that we 
were trying to achieve a high level of continuity between the 
film and game. 

Make your references work for you. Getting useful reference 
photography could be an entire article itself, but there are two 
basic points that can help anyone set up a collection of valu- 
able assets. 

First, you don't need expensive equipment to be effective. For 
Enter the Matrix, we used two 3.1 megapixel cameras and a 
4.0 megapixel camera for important shoots, such as when we 
had sessions with primary film talent. Additionally, we used a 
video camera for overall continuity documentation. We could 
have spent more on equipment, but these cameras served us 
well. With smart purchases, you should supplement your cam- 
era package with a good macro lens for close-up photography; 
remote camera releases to reduce vibration; sturdy tripods, 
lights, and stands for character reference photos; lots of back- 
up batteries; and a neutral screen background for shots of the 
talent. Price shouldn't be a big factor in your decisions, but opt 
for a complete and portable equipment package that can give 
you enough flexibility to handle the unexpected. 

Second, when taking pictures of the primary talent, be 
respectful of the time they are giving you. Create a plan of 
what angles you need, what poses are necessary, and what cos- 
tume configurations you need, and create a checklist for all of 
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Varying stages of Jada Pinkett-Smiths cyber-scan from original files to 
her completed Niobe character. 

this so you can get the shots you need quickly and efficiently. 
An actor's time is precious, and getting them in costume, hair, 
and makeup can be tricky, given their shooting schedules. 
Nothing is worse than spending time with an actor only to 
find out later that you forgot to take shots the designers or 
artists wanted. ("Uh, Jada, can we do another photo session so 
I can get a couple shots of your teeth?") No matter how per- 
sonable the actor is, he or she is not going to be amused to 
hear that you need a second session because you didn't get it 
right the first time. 

Cyber- scanning 

You'll probably be in good hands with just about any firm 
you contract with to provide your scans, and you don't 
need to be a rocket scientist to work with them. But there are a 
few key basics to understand that will serve you well. 

At the very least, you will need body scans of the actors, as 
well as head scans. Going a step further, consider getting scans 
of their hands, and performing body scans in both full costume 
and unitards. While the unitard scans capture the best informa- 
tion on each actor's physique, costume scans are also useful in 
illustrating how the fabric hangs on the actor and the rough 
proportions of different costume pieces. 

As an aside, when doing cyberscans with actors in the uni- 
tards, try to be respectful of the situation they're in. Even 
though the sessions are interesting, resist the urge to have a 
bunch of guys from the development team in the trailer while 
the scans are being performed. The unitards leave little to the 
imagination, so make the talent as comfortable as possible with 
the process by keeping the personnel involved to a minimum. 

Cyber-scanning provides instant feedback — the results are 
right there on the computer monitor. Obviously, the most 
important thing is for the actor to remain perfectly still during 
the scan, or else the subject will produce "waves" in the scan. 
Though the cyber-scan technicians are the best experts on what 
makes a good scan, speak up if you feel a second (or even third 
or fourth) scan is appropriate. The most you'll lose is another 
minute or so of the actor's time, which is well spent compared 
with not having all the scans you need. Remember, you can 
never go back and get more scans. 

www.gdmag.com 



Finally, consider contracting with a cyber-scan company that 
offers a mobile rig. For Enter the Matrix, cyber-scan equipment 
was driven to shooting locations in the U.S. and then shipped to 
Sydney, Australia, to scan actors not available on the U.S. shoot. 

Having the equipment shipped to the film location, even if 
it's in another country, may seem excessive, but it may actually 
result in cost savings when you consider the expenses of bring- 
ing the actors to the equipment via first-class flights and five- 
star accommodations. 

Motion Capture and Facial Capture 

Motion capture is likely one of the most important assets 
on your list. Sessions can last as little as a week or as 
long as several months, depending on the level of detail 
required for the game project, but there are a few general things 
to consider overall. 

The first consideration is the technology you choose for your 
capture sessions. There are several choices for camera types, 
how many cameras will suffice, and what type of rig will be 
built to support the cameras. You will need to carefully screen 
the various contractors that specialize in motion capture and 
pick a partner that offers the best technology for your project 
and your budget. While the technology we used for Enter the 
Matrix was cutting-edge at the time, it is probably already 
obsolete. Shiny held separate sessions for full-body capture and 
facial capture, but some technologies now allow for simultane- 
ous capture of both. 

Plan the costs carefully for your motion capture sessions. It's 
easy to figure out what the mocap sessions will cost from a 
high-level perspective, but are you also considering costs for 
prop construction, catering, and even renting director's chairs? 
Chances are that your initial bid will be much less than the out- 
the-door costs. Plan the budget carefully to avoid massive cost 
overages. It's always better to include all the details in your ini- 
tial budgets that will be up for approval. 

Careful budget planning is always useful, but it's especially 
important for film licenses, because there are potential cost- 
savings in coordinating with the film's visual effects depart- 
ment. Not every film will have visual effects work as extensive 
as The Matrix, but even small films may do some motion cap- 
ture for their project, and if so, it may be a golden opportunity 
to discuss a partnership to save costs. If you can record the 
game mocap at the same time as the film's sessions, costs can 
be shared for the mocap rig, stage time, and talent. 

Working out a cost-saving partnership with the film produc- 
tion will be attractive to your publisher. One downside, how- 
ever, is that joint mocap sessions will probably have to be 
scheduled earlier than your animation team would normally 
plan to conduct their sessions. 

As with the budget, planning is also crucial when generating 
your mocap shot list. In the case of Enter the Matrix, our 
lead animator spent nearly nine months generating his final 
shot list. While the preparation involved may seem excessive, 
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Character sketches, renderings, photographs, and scripts used to plan 
the story line and visuals for Enter the Matrix. 



consider how organized movie productions are. If you aren't 
organized and prepared to the same level, you can easily be 
shut out of the film production's inner circle, which will hinder 
the access you need. 

If you are doing facial capture separate from your main 
mocap sessions, go to similar lengths in planning these sessions. 
The logistics of doing facial capture at the same time as your 
ADR work takes detailed planning, and again, costs can easily 
spin out of control if your technology and shoot days are not 
planned carefully. 

ADR Recording 

One of the most common types of assets licensed games gath- 
er nowadays is voice-over recording with the primary talent. 
When setting up automatic dialogue replacement (ADR) ses- 
sions, be sure to plan your costs accordingly. Whether you are 
doing straight ADR or considering doing facial capture at the 
same time, choose your studio space accordingly. ADR is a fairly 
straightforward process, but things get complicated quickly when 
doing facial capture. Considerations need to be made to accom- 
modate the facial capture rig, segregate the facial capture equip- 
ment in soundproof areas away from the main studio, and spe- 
cial cable runs may have to be planned to maintain the integrity 
of the ADR booth. 

When planning your video reference assembly, be sure to 
check in with the film production. We got in lots of trouble 
during development because we assembled our video reference 
in a way that made sense to us as game developers. We later 
found out that the film people, primary talent, and ADR studio 
were used to working with a video assembly put together in a 
more traditional film format. Weeks of planning went down the 



drain, and we spent tons of time every night redoing the video 
assembly on a portable Avid to prepare for the next day. It was 
a classic case of fallout from inadequate planning between the 
film and game, where each group was used to working its own 
way for its own medium. 

Finally, make sure to plan your shot list carefully. As with 
other types of asset gathering, don't try to get absolutely every- 
thing. You won't have enough time with the talent, and studio 
time is costly. Instead, plan your ADR script carefully, account- 
ing for the gameplay lines you need, cinematic moments, grunt 
sounds for fights, and even promotional lines your publisher 
may want for commercials. If you're also doing facial capture, 
get a range of facial expressions and a phoneme list for your 
animators to use. 

In interviews after our sessions were complete, Jada Pinkett- 
Smith described the ADR/facial capture process as "pure hell." 
This from an actress already familiar with the process from her 
work in productions such as Princess Mononoke. Game ADR 
can be pure hell, for no other reason than the number of varia- 
tions needed for each line to be implemented in an interactive 
title. Understand the position the talent is in, and do them a 
favor by being as organized as possible. 

That's a Wrap 

~ e've just scratched the surface here — every area of asset 
acquisition and management is a subject unto itself. But 
any team placed in a situation with a film production similar to 
Shiny's will face the same fundamental challenges in gathering 
assets. Those teams can benefit from the lessons learned: 

• Create a plan of attack, and pay attention to the details. 

• Figure out what you need and what you don't need. 

• Create in-house systems to deal with asset libraries. 

• Be mindful of the unique environment and of the relationship 
with the talent. 

• Explore cost-savings opportunities with the film production. 
Film productions are masterful examples of organization, 

with plenty of fodder from which the gaming industry can 
learn. Gathering assets is just one slice of the pie — no matter 
the nature of the work, good planning and solid organizational 
principles will be the keys to mutually beneficial relationships 
with Hollywood in the future. 0? 



Thanks to the entire Shiny development team whose passion and 
professionalism helped make the lessons presented in this article 
successful in practice. Thanks also to Rosanna Sun at Eon 
Entertainment who advised me on dealing effectively with 
Hollywood people, whose wisdom is amply reflected here. Finally, 
credit for this production strategy's success also goes to the 
Wachowski brothers for their strong creative vision and commit- 
ment to pioneering new work pipelines. 
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PAUL FROST I Addicted to text-based adventure games as a 
teenager, Paul (frosty@turbinegames.com) always knew he wanted 
to write programs — for games in particular. In 1998 be entered 
the industry working on children s edutainment software, joining 
Turbine Entertainment Software in 2000, Paul is now the tools 
lead engineer and an official runner-up "Unsung Hero." 
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The Tools Development of 

Turbine's Asheron's Call 2 




ames bound for today's 
marketplace require the 
development of soft- 
ware tools. Whether the 
tool is a simple script to 
search text files for art asset file names, 
a complex model and animation 
exporter, or a massive world builder, 
these tools help game developers get 
the job done quickly and efficiently. 
The subject of tools arises in practically 
every Game Developer Postmortem, 
falling evenly into the "What Went 
Right" and "What Went Wrong" cate- 
gories. Our tools development process 
at Turbine Entertainment Software 
underwent a lot of change during the 
Asheron's Call 2: Fallen Kings prod- 
uct cycle. This is what we learned. 

During development of the original 
Asheron's Call, we created tools as 
needed — even the world-building tools 
were left until the alpha timeframe. 
While this off-the-cuff approach to 
tools development allowed the engi- 
neers to spend their time creating fun- 
damental engine features, it left the 
artists and content designers out in the 
cold, forcing them to edit many text 
files by hand. The process of text- 
file manipulation was error- 
prone and lengthy; 

Turbine resolved 




to do things better. 
For AC2, Turbine made a con- 
scious effort to be more tools-aware 
when developing its next-genera- 
tion engine. The core engineering 
group developed tools in tandem 
with the graphics, client/server, 
animation, and physics systems. 
Engineers were asked to expand 
their object interfaces, encompass- 



ing functionality not only for the 
client but for the tools as well. Tools- 
awareness was not limited solely to 
the core engineering group as it was 
with AC1. 

We had several goals in mind while 
planning for AC2 tools functionality: 
First, we did not want to lag behind 
the engine development. The tools 
would reflect the current state of the 
engine, allowing users to test and use 
features immediately. Second, because 
AC2 would be much larger than AC1, 
we needed to speed up content itera- 
tion. The ability to preview and tweak 
engine assets without having to reload 
the client after each modification was 
critical. Finally, we wanted to hide the 
complexity of the engine from our 
users. Interfaces to revision control, 
logically organized dialog boxes, and a 
rendering window that was identical to 
the client facilitated use of the tools. 
We found that being so closely tied to 
the development of the Turbine Engine 
greatly benefited our tools. 

What Went Right 

1 Management and corpo- 
# rate buy-in. From the begin- 
ning, Turbine's vision for our internal 
tools was far-reaching. Many changes 
were being made to the Turbine Engine 
for AC2, so the idea of having a core 
engineer develop tools only part-time 
or wait until later in the content cycle 
was foolhardy and dangerous. We 
decided to create a dedicated tools 
position in the core engineering staff, 
recognizing that having a full-time 
engineer available for tools develop- 
ment would address many of the artist 
and content designer concerns. Instead 
of leaving tools development until the 
majority of the assets had already been 
created, the tools would be authored at 
the same time as the engine. 

But what good is a full-time position 
without a plan? Turbine had several 
clear goals for the tools development 



process for AC2 and a roadmap to get 
there. We planned sufficient time, sched- 
ules, and resources for the process: we 
did not want to be developing tools at 
the alpha stage or spending nights and 
weekends cobbling together code to get 
the job done. We drafted milestones and 
goals for the tools that aligned to con- 
currently developing features in the 
engine. Through tool prototyping, we 
often discovered engine bugs early in the 
process. We also learned in the process 
that while schedules are nice, flexibility 
in tools development is critical; we often 
were required to rearrange our mile- 
stones and due dates based on function- 
ality that the users needed "now." 

Additionally, employees outside the 
core engineering group provided plenty 
of support. Artists, game systems engi- 
neers, and designers had helpful opin- 
ions and input into the tools develop- 
ment process. We brainstormed tool 
features and prioritized our lists. As the 
tools lead, I was able to schedule artists 
and designers to produce content used 
to prototype tools and work out bugs 
prior to their release. The company's 
support made my job that much easier. 

2 Leveraging the engine 
• code wherever possible. 

Turbine built the original set of world- 
building tools for Asheron's Call 
using the actual Turbine Engine game 
user interface. This presented a few 
problems: long compilations and 
tweaking screen sizes and positions 
made tools work unpleasant. Moving 
forward, Turbine decided that the tools 
should provide a consistent interface 
around an engine-rendered viewport. 
We developed the game on and for the 
Windows platform, so it seemed natu- 
ral that the tools should be as well. 

Several benefits were immediate: 
With the user interface and rendering 
engine separated, code could more easi- 
ly be shared between the tools and the 
engine. WYSIWYG — what you saw in 
the tool-rendering viewport was what 
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you got in the client. Many lighting and visual effects could be 
previewed and adjusted before building client data, which saved 
a great deal of time. The flexibility of Visual Studio allowed us 
to lay out dialog boxes quickly and gave us the ability to use 
window controls, such as listboxes and tree views, that weren't 
currently available in the Turbine Engine game UI. We also 
extended existing window controls to provide object information 
in new and logically organized ways. Using the English text rep- 
resentations of enumerated type data in listboxes aided the 
designers with easily understandable names, while at the same 
time prevented errors that would occur if those enumerated types 
were entered by hand into a text field. As a result, we dramati- 
cally reduced broken builds due to bad data. 

A common API of virtual functions was provided for every 
object in the database. This made each instantiatable object 
"tools-compliant." Our world-building and art asset tools 
could query, modify, and update any object with the correct 
interface calls, which spawned one of the favorite expressions 
at Turbine: "Every engineer is a tools engineer." Engineers 
could use the common API to create new database objects with 
tools functionality built right in. Failure to fill in the API hooks 
resulted in debug assertions when an object of that type was 
loaded into the tool. Distributing the workload of tools devel- 
opment at the lowest level forced other engineers to provide 
previously omitted functionality. I would often find that pro- 
viding functionality for a new object type became trivial; the 
majority of code had already been written. 

3 Frequent tools design discussions. Turbine's inter- 
% nal tools cover a wide range of functionality. Art and 
content tools allow the user to preview and tweak all art assets 
before they are converted into the game data. World-building 
tools provide fast modification of terrain and the ability to place 
art assets into the game world easily. Engineering tools automati- 
cally generate code and data files and provide an interface to the 
source control system. At the beginning, there were hundreds of 
tools tasks that needed to be organized and prioritized. 

Early in the tools development process we created two com- 
mittees: one to address art and asset concerns and one to 
address world-building concerns. These committees met week- 
ly, consisting of representatives from each functional area at 
Turbine: art, design, engineering, and game systems. The sta- 
tus meetings permitted opportunities to brainstorm new func- 
tionality, discuss problem areas and possible solutions, and 
reprioritize task lists and schedules. In this way, everyone felt 
they had input to the tools process, making it "our job" 
instead of "my job." 

Keeping people up-to-date was a high priority. Daily status 
reports to a centralized mailing list let any interested artist or 
designer see what was happening to the tools. When new versions 
of the tools were checked in, another mailing list identified the 
new features, the bugs fixed, and the next required tasks. Each 
month, we prioritized the list of outstanding tasks and reshuffled 
the schedule, if necessary. We probably kept people too informed, 
but the adage "forewarned is forearmed" was definitely true. 




Monster placement inside a dungeon in AC2. 



4 Feedback, feedback, feedback. Unlike Turbine's 
O monthly episode cycle where the client program is 
released to thousands of subscribed users, all internal tools 
were built daily and provided only to those who wanted them. 
The customer wasn't hidden behind a bulletin board or an 
anonymous IP address. And, in some cases, my customer was 
the person sitting right next to me. When they were unhappy, 
boy did I hear about it. Continual feedback made the tools bet- 
ter, but we worked hard to create productive feedback loops. 

One single point of contact existed for all tools-related ques- 
tions, problems, and enhancements: me. While this provided me 
with the opportunity to extend my organization skills, it also 
gave the users comfort to know that someone was always look- 
ing at a problem. ICQ and MSN Messenger gave the artists and 
content designers a way to contact me at any time. However, 
walking over to a desk and checking out a problem is often the 
only way to catch a crash that has no good reproduction case. I 
made a point to provide feedback as soon as possible, even if I 
was just letting a user know I couldn't get to their problem 
immediately or that their enhancement would be added to the 
list of items to discuss at the next committee meeting. 

A program crash is always unwelcome, especially when 
artists and content designers get in the groove of creating con- 
tent. When a crash occurs, they will sigh, curse the program, 
and reload to continue what they were working on. I had no 
idea how often our tools crashed, and the users were more 
interested in getting work done than in reporting problems. We 
overcame mystery crashes by using a common "assert" dialog 
box in the debug versions of all Turbine's software: the tools, 
the client, and the server. This dialog box contained a stack 
trace, an optional message, and a Send E-mail button. Sending 
the e-mail directed the contents of the dialog box to an internal 
mailing list. Program crashes still put out the artists and design- 
ers, but now there was a clear record of where — and some- 
times how — the assert occurred. The entire core development 
team monitored the assertion mailing lists, which proved to be 
very useful. For critical problems, we set up the development 
environment on every machine in the office. If a problem need- 
ed resolution immediately, or there was no good reproduction 
case, we could break out of the assertion dialog box directly 
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LEFT. AC1 s world-building toolset. CENTER. The town of Zu seen from AC2 s world-building tools. RIGHT. Zu, as viewed in the AC2 client. 




into the code and analyze the stack at that point. This was use- 
ful for debugging not only the tools, but debug versions of the 
client as well. 

In some cases, the assertion mailing lists were insufficient to 
track the progress of a problem. When a problem severely 
affected the performance of the tools, we entered bugs into 
Bugzilla, the open source defect-tracking system. Bugzilla pro- 
vided us with several important benefits: an HTML interface 
for reporting, modifying, and querying bug status; an e-mail 
interface to notify the appropriate engineers; and, because it's 
open source, a very attractive price tag. Once the baseline tools 
functionality was implemented, the ability to get a listing of 
bugs, priorities, and due dates was indispensable for organizing 
a daily or weekly task list. 

5 We met Our goals. There was a sense of accomplish- 
# ment when Asheron's Call 2: Fallen Kings moved 
from production to Live Team support, not only from the client 
and server teams, but with respect to the tools as well. "Meeting 
our goals" may sound trite, but the Live Team would be using 
the tools we produced going forward as they created content for 
the monthly episode cycles. A defined list of objectives let us sys- 
tematically fulfill the needs of the artists and content designers. 

Our first major goal was to speed up content iteration, 
which we did in several ways. To remove the possibility of 
entering bad data into the tools, menus and lists were pre-pop- 
ulated only with valid options. Allowing the database objects 
to reload in place from disk, artists could change models and 
textures behind the scenes, which eliminated the "modify, shut- 
down, reload" shuffle. Finally, overnight generation of data 
became possible by enabling batch processing of various assets. 

Hiding the engine complexity from the user was our second 
major goal. By using an engine-rendered viewport in the tools, 
we guaranteed that content visualized in the tools would be iden- 
tical to the client. We also created APIs into external tools; 
enabling us to add revision control functionality and remove 
some checkout/merge/check-in problems. Next, we presented 
coherently organized data; we imposed a visual structure on the 
data hierarchy and clarified our database inheritance scheme. 
Lastly, by modifying our build system, we were able to automati- 
cally get the latest code from source control, build any number 
of executables, and e-mail the user with a summary status at the 
completion of the job. 

Overall, our internal tools development was worth the effort 
we put into it. 



What Went Wrong 

1 Coding before design. All the old lessons drummed 
O into my head during school still apply: design in any 
complex software system is crucial and cannot be skipped. In 
the early phases of tools development, I tended to jump right 
into the code pile and start hacking out a solution to the prob- 
lem. This caused no small amount of headaches when a seem- 
ingly small task blossomed into a days- or weeklong struggle. 

Our art asset tools were originally limited in that we could 
edit and load only a single entity at a time. To speed content 
placement, it soon became apparent that we would need to 
create groups of entities. Doing so meant loading multiple 
objects into the tool concurrently and providing grouping/ 
ungrouping functionality. I jumped into the task and finished 
in less than two days. When demonstrating the process to the 
users, it turned out that several important features had been 
skipped, prompting questions such as: What world-space 
position were the entities moved and rotated relative to? If 
one object in the group was selected, was the whole group 
selected? Did the tool remember if several different groups 
were created? My understanding of the problem wasn't com- 
plete and it showed. It was a frustrating lesson to be learned 
all around. 

Obviously, more up-front design would have saved lots of 
time in this case. I now create a one-page, high-level summary 
of new features, which I have affected parties sign off on. A 
detailed design, usually down to the class and interface level, 
takes just less than a day. Applying this procedure cut tools 
development time by about 30 percent and drastically reduced 
the number of migraines I take home. 

2 Feedback, feedback, feedback. As mentioned 
9 previously, creating our feedback loops was a lot of 
work. In the beginning, there wasn't much feedback from the 
users. Content designers did not realize that tools programmers 
didn't use the feedback functionality in the same manner; when 
the program crashed, they figured, "That's the way it is." Users 
found creative workarounds for various problems: "Don't press 
the 'V key when your object is selected or it will crash." Later 
in the design process, I got a lot of requests for desired features 
which ended up being used rarely, if at all. During content 
crunch periods, feedback was nonexistent. 

The dungeon creation process in AC2 highlighted a good 
example of feedback problems. Originally, the tech specified 
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400 objects in a dungeon, including all lights, decorations, 
creatures, and structures. However, late in the AC2 process, 
designers hated working on dungeons, especially when the 
number of objects ballooned to more than 1,000 objects: tele- 
porting into and loading a dungeon location could take 
upwards of 20 minutes. Once loaded, rendering the dungeon 
yielded one to two frames a second; every object was drawn 
regardless of its distance from the camera. The content team 
shouldered these issues stoically, so I didn't find out about it 
until I had the chance to build a dungeon myself. 

It turned out that the process of loading a dungeon recur- 
sively built an internal graph of data connections every time a 
new object was loaded. This system worked fine for 400 
objects, but got worse the more objects were added. A few 
lines of code to pause the data graph construction during 
loading dungeons and functionality to cull objects at a user 
configurable distance dropped load times to 45 seconds and 
increased frame rate to a manageable 15 fps. 

I have since learned to schedule some time for myself where I 
can use the tools in several different circumstances. There's 
nothing quite like getting a taste of your own medicine to spur 
improvements. 



3 No good testing regimen. Insufficient testing 
O plagues any software designed for internal use only. 
Many different trade-offs must be considered: How much time 
and effort is going to be spent testing a product that isn't going 
to generate revenue? Who is responsible for the testing of the 
internal tools, the developer or the quality assurance team? 
And how much of the QA budget can be utilized testing tools 
instead of the client? 

The developer making the change in a specific area would 
usually test our tools and administer a functional overview test. 
Such limited and random testing didn't find many problems, so 
usually the users would end up being the alpha, beta, and pro- 
duction testers. Every so often we ran across problems big 
enough that they required several new versions of the tool to 
fully isolate and fix them. Having users on different versions of 
the code base led to several head-scratching dead-ends before 
the version inconsistency was recognized. 

We started solving this problem with a growing internal QA 
team and the diligent use of bug-tracking systems for our tools. 

4 Engine limitations. Wrapping a rendering view- 
9 port with a Windows system provided many bene- 
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fits, but ended up causing other problems. The world-building 
tools allowed users to switch between three different work- 
spaces: an entity workspace to preview and tweak art assets, a 
world-building workspace that allowed content placement and 
terrain modification, and a dungeon-building workspace for 
assembling dungeons and placing creatures. Since the tool 
never knew what the user would be working on, massive 
amounts of memory were required to make sure all assets 
were preloaded, adding to the amount of time the tool needed 
to start up — going from double-click activation to "ready to 
work" took up to five minutes. 

As I mentioned earlier, having the tools and engine closely 
bound was beneficial, allowing the core engineering team to 
find bugs in the Turbine Engine earlier. On the other hand, 
every memory leak or problem in the engine was exacerbated in 
the tools. One of the goals of the tools called for handling data 
errors cleanly and permitting the loading process to continue; 
users would be warned and their object would fail to load, but 
the program wouldn't crash. Such was not the case: text files 
that failed parsing by the low-level loader often caused a nonre- 
coverable crash, which required restarting the tools. 

It also turned out that not all engineers were tools engineers. 
We found a few cases where one of the tools API functions 
returned "true" from a virtual function but provided no actual 
code. Developing a Windows application also has its own quirks 
and can be difficult for engineers unfamiliar with the framework. 

Finally, we wrote the tools generically to handle core func- 
tionality that could be shared across games using the same ver- 
sion of the Turbine Engine. It turned out to be difficult to inte- 
grate game-specific functionality on top of the existing tool set. 

Going forward, we have resolved to educate our engineers, 
create smarter objects, handle assets smartly and completely, 
and use profiling tools whenever possible. We're still working 
on the load times. 

5 Lack of tools documentation. Implementing new 
9 features and fixing bugs requires the majority of tool 
development time. There doesn't seem to be enough time in the 
day to write documents and get the work done. "How-to" docu- 
mentation takes a good amount of time to do well, and it's a task 
not everyone enjoys. The AC2 content process suffered from a 
lack of tools documentation, and since the tools knowledge had 
to be passed by word-of-mouth from content designer to new 
hire, we lost valuable time. There were a few short documents 
describing complex features, but roughly 30 to 40 percent of the 
functionality went unused because no one knew it was available. 

Moving forward, we created an internal "tools news" mail- 
ing list. When new tools were compiled, the list was updated 
with the new version's features, bugs resolved, and short "how- 
to" information. However, not everyone read the mailing list, 
and I would regularly get questions for how processes worked 
and feature requests for tools that already existed. In the future, 
we hope to have more documentation and as a team be more 
committed to both updating and referencing it. 




Editing an animation on the Gurog Lord using AC2"s art asset tools. 



Tools of the Trade 

As games become larger and more complex, the potential 
for build-breaking errors becomes more and more likely. 
Software tools — both internal and external — can provide 
many features: error checking, error prevention, content gen- 
eration, and productivity enhancements. If someone must do a 
repetitive, complex, or boring task, a software solution is 
ideal. During Asheron's Call 2, Turbine vowed to be smarter 
about tools development and planned accordingly. 

At Turbine, we devoted roughly 20 percent of our core 
engineering budget to tools work. With a dedicated engineer 
and a plan for tools functionality, we knew exactly what we 
needed to accomplish and how we hoped to do it. The team 
found that sharing code between the Turbine Engine and the 
tools saved a lot of time previewing and tweaking art assets. 
We learned that design is critical for any software project, 
not just our client software. Feedback and discussions gave 
everyone a vested interest in the tools. We've got some work 
to do for testing and documentation, but we're moving in the 
right direction. 

Tools developers know theirs isn't the most glorified posi- 
tion in a game company, but it is one of the most critical. 
People at fan gatherings don't want to talk to you, and half 
the people in your company don't know exactly what you do. 
Your job can be the bottleneck that strangles a game, and you 
may ask, "Is it worth it?" A content designer once told me 
that in the original Asheron's Call, he destroyed the town of 
Arwic using the first-generation terraforming and content 
placement tools. Time spent? One week. Modifying a similar 
set of terrain for Asheron's Call 2 with the new tools took 
an hour and a half. I'd call that improvement. 0? 
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Turning Games into 
Learning Machines 



C 




ognitive sci- 
ence is the 
study of how 
human beings 
learn and 
think. Cognitive scientists 
study learning and thinking 
in laboratory experiments 
and out in the world by 
designing and testing new 
ways of learning in work- 
place and classroom settings. 
Though game developers can 
learn a good deal from cog- 
nitive science about how 
to get more people to 
learn and enjoy their 
games, cognitive scientists 
can learn a good deal from 
good game developers about 
how their theories can be 
applied to how people learn. 

I am a cognitive scientist 
who, at the ripe old age of 53, started playing videogames. Much 
to my surprise, I discovered many modern games to be long, 
complex, and challenging endeavors. Judging by their increasing 
popularity, millions of people willingly go through the process of 
learning how to play these games. Otherwise, no one would be 
buying them and a lot of you reading this would be out of a job. 

Good videogames encourage types of learning and thinking 
that are important in today's fast-paced world. Today's young 
people — who were raised on and still are consumers of 
videogames — are often better at these types of learning and 
thinking than their baby-boomer parents. However, this is not 
because games operate at "twitch speed." I play Pikmin less well 
than my seven-year-old son, and twitching has nothing to do 
with it; he is simply better at exploring and problem-solving in 
the game's world than I am. Good games tend to encourage 
exploration rather than straightforward movement to a goal. 
They encourage players to redefine goals as they move forward, 
to seek multiple routes to goals and multiple solutions to prob- 
lems. In fact, many game developers would not consider it an 
honor to have their game described as "linear." In today's world, 
where everything interacts in complicated ways with everything 
else, such nonlinear thinking is a requisite for progress. 

We — both the game development industry and cognitive sci- 



entists — have a lot to learn from how 
good games are designed to 

enhance learning and how they 
can be made even better. This 
research will in turn lead to 
more engaging and better-playing 
games. It will also lead to the realization of 
the immense and innate potential that 
games have as learning tools, both inside 
and outside classrooms. 

Why Games are 
Great Learning 
Machines 

Games like Rise of Nations, 
Deus Ex, or System Shock 
2 have a plethora of good learn- 
ing principles built into them, 
principles that reflect what cut- 
ting-edge cognitive research has 
discovered about what causes 
deep human learning: 

The "cycle of expertise" principle. Learning is not primarily 
about tutorials. Cognitive scientists know that humans enjoy 
learning experiences that revolve around the "cycle of expertise," 
a cycle comprising five different stages, which can be applied to 
game situations as follows: Beginning in stage 1, players are con- 
fronted with problems specifically designed to make them form 
good generalizations about the game, generalizations that will 
really pay off for them later on when the gameplay becomes 
more advanced. During stage 2, players are made to solve related 
but varied problems until they attain a routinized mastery of 
these problem-solving skills. 

In stage 3, game designers will throw a new problem at players 
that requires both those previously acquired skills and the devel- 
opment of new ones. By doing this, they make players reopen 
their existing cognitive tool kit and expand it with new skills. 
These new problems, with variation, are now repeated enough to 
create a new routinized tool kit in stage 4. In stage 5, the whole 
cycle is repeated. Though these stages exist in most kinds of deep 
learning, in a game it means that learning and playing become 
synonymous for the duration of the game as players move up a 
ladder of increasing learning and mastery. 

continued on page 55 
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continued from page 56 

The "pleasurable frustration" principle. Players are most moti- 
vated to learn and keep learning (and keep playing) when the 
game operates within, but at the outer edge of, their sphere of 
competence. The feats facing them must feel doable but chal- 
lenging at the same time, giving rise to a constant sense of pleas- 
urable frustration. Players should be able to customize games 
according to their own levels of competence and their learning 
and playing styles. This is not just a matter of having different 
difficulty levels; it is also a matter of allowing multiple solutions 
to problems, of offering differential rewards for different levels 
of play, of giving choices about save systems, and of offering 
regular feedback about the player's progress. Games should get 
progressively harder for those doing too well or ease up a little 
for those faring poorly. 

The "sandbox" principle. For cognitive science purposes, sand- 
boxes describe little bounded pieces of the real world where 
one can explore while still feeling safe. In a game, the first or 
early levels of a game should serve as the player's sandbox. 
Tutorials are great so long as they give just enough information 
to get players quickly learning by playing. When a game's first 
level or levels serve as virtual tutorials, players feel they are 
actually playing the game when in fact they are being tutored 
on how the world works. Players feel at risk, but the risks are 
really minimal. Sandbox levels offer players lots of examples of 
the basic elements of the game, so they can later concentrate on 
the new, special, and harder aspects they will face in subsequent 
levels (this is called a "concentrated sample" in the cognitive 
research field). 

Motivation: Saving the Best for 
Last 

The learning principles of a good sandbox, the cycle of 
expertise, pleasurable frustration, and others like them are 
actually part of what makes a game feel "deep," and hence 



enjoyable and memorable. For humans, the best learning is 
playing, and the best playing is learning. 

The most important factor that drives learning is motivation; 
when motivation dies, learning dies and playing stops. One of 
cognitive science's definitions of motivation (it is one of those 
hard-to-pin-down words) is a learner's willingness to make an 
extended commitment to engage at a personal level in a new area 
of learning. Players immersed in good games can help us study 
how motivation in this sense is created and sustained, since good 
games appear to be highly motivating to a great many people. 

When playing a videogame, players engage in "action at a dis- 
tance," much like remotely manipulating a robot, but in a far 
more fine-grained fashion. Cognitive research suggests that since 
perception and action are deeply inter-connectedfor humans, this 
fine-grained action at a distance actually causes humans to feel as 
if their bodies and minds have stretched into a new space. Books 
and movies, for all their virtues, cannot do this. The more a play- 
er can manipulate a character and the more the player's decisions 
impact on that character, the more the player invests in the char- 
acter and the game at this biological level. This investment forms 
the deepest foundation of a player's motivation to stick with and 
eventually master a game. In this sense, failing to build good 
characters risks losing the biggest advantage a game has. 

Cognitive science owes a considerable debt to the game 
industry for providing large-scale validations for its principles 
and theories in action. At the same time, game developers' con- 
scious application of these principles and theories stands to 
return the favor by delivering compelling learning and emotion- 
al experiences unique to human behavior, if 
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